Des normes appliquées de la même façon sur chaque mission, c’est ce qui permet à une petite équipe de développement de garder son rythme au-delà du premier mois. Voici ce que cela donne en pratique.
Une bonne partie de ce que l’on appelle agile n’est que de l’improvisation assortie d’un stand-up. Cela paraît rapide le premier mois et ralentit chaque mois suivant, parce que les décisions jamais écrites doivent être redécouvertes, et que les intégrations jamais spécifiées cassent en production.
Nous menons nos missions de développement dans l’autre sens : un peu de structure d’abord, appliquée de la même façon à chaque fois, puis autant de vitesse que cette structure le permet. Une mission récente en sous-traitance, la réalisation de tableaux de bord opérationnels pour un éditeur de logiciels, montre bien ce que cela signifie en pratique.
Chaque mission commence par un document d’architecture de la solution, rédigé avant le développement. Il est court, et c’est explicitement un document vivant. Il indique ce que fait le système, la technologie dans laquelle il doit s’insérer, les points d’intégration, les hypothèses et, tout aussi important, les exclusions.
Pour les tableaux de bord, les hypothèses précisaient ce que chaque vignette afficherait, quels flux de données l’alimenteraient et le fait que les structures de données fournies étaient figées, et les exclusions étaient tout aussi précises. Chacune de ces phrases supprime un débat qui aurait sinon lieu au milieu d’un sprint.
Les tableaux de bord sont alimentés par des imports planifiés d’extractions de tableur. Rien n’est importé de confiance. Un importeur de base lit chaque fichier et le valide par rapport à un schéma défini avant toute persistance : une colonne renommée ou un onglet manquant provoque un rejet clair dès l’entrée, et non un chiffre faux sur l’écran d’un responsable trois jours plus tard.
Le même raisonnement vaut pour toute intégration. Définir le contrat, valider par rapport à lui, et rendre l’échec visible.
La première phase lit des fichiers déposés sur un emplacement FTP. La seconde remplace ce mécanisme par une API. Le chemin FTP est conservé comme solution de repli lorsque l’API n’est pas disponible, et l’ordonnanceur qui exécute les imports assure la journalisation et les nouvelles tentatives automatiques.
C’est un petit effort supplémentaire au moment de la conception, et c’est la différence entre un tableau de bord parfois en retard et un tableau de bord parfois vide.
Nous appliquons ces pratiques sur chaque mission.
Gestion de versions et pipelines. Le code est placé sous gestion de versions, chaque modification est relue, et chaque modification est compilée et testée par un pipeline avant de pouvoir être déployée.
Des environnements séparés, au contrôle croissant. En développement, les déploiements sont libres. La préproduction et la production suivent le processus de changement du client, en général une demande de changement écrite avec les risques et un plan de retour arrière, puis un passage en comité consultatif des changements avant la production.
La sécurité dans le pipeline. L’analyse statique du code comme socle, chaque ligne ajoutée étant analysée sous l’angle des normes, de l’architecture et de la sécurité avant d’être validée, l’analyse des dépendances lorsque le client la choisit, et les tests dynamiques comme activité délibérée et planifiée.
Une passation écrite. La documentation nécessaire pour faire fonctionner le système au quotidien est remise à la mise en production.
Comme les normes sont les mêmes partout, un ingénieur qui passe d’une mission à l’autre n’a pas à apprendre une nouvelle façon de travailler, et un client peut voir à l’avance exactement comment son logiciel sera construit, testé et publié.
La structure a l’air d’un surcoût. En pratique, elle supprime le type de retard le plus coûteux : découvrir au troisième mois ce qui aurait pu être décidé la première semaine. Une petite équipe dotée de normes claires passe son temps à construire. Une grande équipe qui en est dépourvue passe le sien à réconcilier.
La façon dont nous appliquons tout cela, désormais avec l’assistance de l’IA au sein de la même discipline, est décrite sur les pages Engagement et livraison assistés par l’IA et Développement et ingénierie logicielle.
Fait partie de la série Retours de nos projets. Recevez les nouvelles analyses par e-mail ou suivez le flux RSS.
Les données non structurées sont la moitié la plus difficile du retrait d’une ancienne plateforme. Quand les documents sont au cœur du travail quotidien, l’objectif est une migration que les utilisateurs ne remarquent jamais, et le risque se loge ailleurs que dans le code.
L’essentiel de notre travail consiste à construire des logiciels qui appartiennent à un client. UMOYA Zone est différent. C’est une coentreprise, et être copropriétaire d’un produit nous a appris des choses que le travail pour des clients n’enseigne pas.
Quand un investisseur regarde sous le capot d’une plateforme en croissance, les questions portent sur les identifiants, les données et la réalité des corrections. Ce que nous avons appris en menant une due diligence technique de la première revue jusqu’à la remédiation vérifiée.
