Chez Access it nous avons depuis longtemps fait le choix d’investir du temps dans le développement et la maintenance d’un socle technique pour un gain de temps sur l’application métier.
Ce choix a été motivé conjointement par nos Tech Leads et Product Owners, afin de répondre à des problématiques diverses, comme l’uniformisation des technologies, la fiabilité des développements, la rapidité de réalisation sur les applications métiers et enfin de proposer des interfaces utilisateurs simplifiées avec une identité graphique au goût du jour.
En ayant une librairie de composants partagée, on obtient un code qui a été testé et éprouvé au travers des différents projets qui en ont bénéficié.
Ainsi lorsqu’un projet démarre, on sait par avance que les bugs purement techniques, comme l’impossibilité d’envoyer des emails ou de se connecter à la base de base de données, seront rares ou indépendants de notre volonté : le serveur d’envoi de mails ou de BDD ne répond plus.
Cela permet aux développeurs de se concentrer au maximum sur les développements des règles sur l’application métier de nos clients, ce qui réduit les temps de recette car le nombre de retours est moins important. Comme le risque zéro n’existe pas, il peut toujours arriver qu’un problème soit détecté et nécessite une correction. Dans ces cas-là, le correctif est réalisé directement dans le socle technique et peut être rapidement déployé sur d’autres projets avant même qu’il ne se soit produit ailleurs.
Comme je le disais précédemment, le socle technique permet aux développeurs de se concentrer sur les règles métier de nos clients.
Certains développements très techniques ne diffèrent jamais d’un projet à un autre. Aucun développeur ne devrait se demander à chaque projet comment envoyer un email, générer un fichier PDF ou gérer l’authentification des utilisateurs.
Grâce au socle technique, tous ces développements ne sont plus à refaire. En tant que développeur je ne dois plus me demander comment je dois faire un développement, ou bien sur quel ancien projet je l’ai déjà fait pour aller m’en inspirer. Tout ce que j’ai à faire c’est utiliser le socle technique qui le fait à ma place, et en faisant ce choix je sais que cela sera fait correctement.
Je parle depuis le début de cet article de briques techniques qui concernent plutôt les APIs, mais cela est aussi vrai pour la partie visible des utilisateurs
Après plusieurs années passées dans le développement Web, j’ai appris que le plus long dans un projet ce n’est pas l’implémentation des règles métier, mais la création des interfaces utilisateurs.
Bien souvent nos clients souhaitent tous la même chose : les grilles doivent être triables et filtrables, les champs texte doivent respecter un certain format, le menu doit pouvoir se réduire etc.
Sans socle technique, tous ces développements devraient être refaits d’un projet à l’autre.
QUID des clients qui ont leur propre charte graphique et qui nous fournissent des maquettes ? Nous avons bien entendu prévu cela et rendu le socle totalement personnalisable.
Pour les clients qui préfèrent nous faire confiance sur la charte graphique de leurs applications, nous laissons le style par défaut du socle. Ainsi ils bénéficient d’une interface au goût du jour sans coût supplémentaire.
Tous nos développeurs sont formés à son utilisation. Cela facilite beaucoup la gestion des équipes car en cas d’absence d’un développeur (hé oui, même nos supers développeurs tombent malade de temps en temps) on peut facilement le remplacer par quelqu’un qui sera tout de suite opérationnel techniquement, seules les règles métier spécifiques au client impacté devront lui être expliquées.
Ainsi nos clients ne souffrent pas de retards de livraisons car nous avons toujours la capacité de le remplacer par un autre développeur d’un profil équivalent.
Chez Access IT, nous avons une forte expertise dans le développement d’applications métier client/serveur basées sur Vue.js (5 bonnes raisons de choisir VueJS) et .Net (Décryptage de .NET 8). C’est donc tout naturellement sur ces deux technologies que notre choix s’est porté pour le développement de notre socle technique.
À l’heure où j’écris cet article, la partie API est développée en .Net 8 et la partie interface utilisateurs est réalisée en Vue.js 3.5 et avec le framework Quasar. Nous les mettons à jour dès qu’une nouvelle version est publiée par Vue.js et Microsoft afin que nos clients soient toujours sur les versions les plus récentes et bénéficient des derniers correctifs de sécurité et des meilleures performances possibles.
