Méthode:Process[6]
Six étapes, dans cet ordre, avec un livrable à chacune. Vous savez à tout moment où en est le projet et ce qu'il reste à faire.
Une méthode ne vaut pas par son organigramme mais par ce qu'elle rend impossible. Celle-ci rend impossible de découvrir un dérapage à la livraison : chaque étape produit quelque chose que vous pouvez ouvrir, et une démo a lieu même quand il n'y a rien de réjouissant à montrer. Ce sont les démos-là qui comptent. Les six étapes ci-dessous ne sont pas un rituel figé : sur une reprise d'existant, le cadrage devient un audit et la mise en production arrive beaucoup plus tôt, par petits morceaux.
Ateliers d'expression du besoin, cartographie des utilisateurs, contraintes techniques et priorisation.
Le cadrage sert à découvrir ce qu'on ne savait pas avoir à décider. Ce n'est pas une étape de recueil : personne n'arrive avec un besoin complet dans la tête, et prétendre le contraire produit un cahier des charges qui décrit une solution imaginée plutôt qu'un problème réel.
Nous travaillons donc par questions plutôt que par formulaires. Qui utilise le logiciel, dans quelles conditions, et que se passe-t-il quand il ne fonctionne pas ? Cette dernière question est celle qui révèle le plus : elle sépare ce qui doit être irréprochable de ce qui peut attendre, et cette séparation détermine tout le reste du projet.
Une liste de fonctionnalités est plate : tout y paraît également important, parce que rien n'y est rattaché à quelqu'un. Nous partons donc des personnes. Le technicien qui saisit debout avec des gants, la comptable qui traite quarante dossiers d'affilée au clavier, le dirigeant qui ouvre un tableau une fois par mois : trois usages, trois exigences opposées, et une seule application.
Ce travail met presque toujours au jour un utilisateur oublié. Le plus souvent celui qui reprend le travail quand quelque chose s'est mal passé : le support, l'administrateur, la personne qui corrige la saisie de quelqu'un d'autre. Ces gens-là ne sont jamais dans le cahier des charges initial, et ce sont eux qui utilisent le logiciel le plus longtemps chaque jour.
Certaines contraintes coûtent très cher quand on les découvre tard : un système tiers dont l'API n'existe pas, un hébergement imposé, une obligation réglementaire sur la localisation des données, un poste de travail figé sur un navigateur ancien. Nous les cherchons activement pendant le cadrage, parce qu'elles ne se déclarent pas d'elles-mêmes.
La question qui les fait sortir n'est pas « avez-vous des contraintes », à laquelle tout le monde répond non. C'est « qu'est-ce qui a fait échouer le dernier projet informatique ici ». La réponse est rarement technique et presque toujours instructive.
Nous donnons une fourchette et l'hypothèse qui la soutient, pas un chiffre unique. Un chiffre unique est faux dans 100 % des cas ; la seule question est de combien, et c'est précisément ce qu'une fourchette rend visible. Quand l'écart entre le bas et le haut est trop grand pour décider, cela veut dire qu'il manque une information, et nous disons laquelle plutôt que de moyenner.
Nous refusons en revanche d'estimer au jour près à ce stade. Une estimation détaillée sur un périmètre encore flou donne une fausse précision, et cette fausse précision devient un engagement dans les esprits. C'est ainsi qu'on se retrouve à défendre un chiffre écrit avant de connaître le sujet.
Nous avons cadré des projets sans jamais rencontrer les utilisateurs finaux, en nous appuyant sur ce que leur direction en disait. À chaque fois, l'écart s'est révélé à la première démonstration, et il a coûté plus cher que les deux jours d'atelier que nous avions cru économiser. Nous demandons désormais l'accès aux utilisateurs comme une condition, pas comme une préférence.
Écrit au passé, parce que nous y sommes passés.
Architecture cible, ADR, maquettes fonctionnelles, design system et modèle de données.
Cette étape produit des documents, et les documents ont mauvaise presse pour une bonne raison : la plupart ne sont jamais relus. Nous n'en écrivons donc que trois sortes, celles qui répondent à une question qu'on se reposera. Tout le reste se périme avant d'avoir servi.
L'architecture décidée ici n'est pas gravée. Elle est faite pour être révisée quand la réalité contredit une hypothèse, ce qui arrive. Ce qui compte est que la révision soit consciente : on doit pouvoir dire ce qu'on change et pourquoi, plutôt que de dériver sans s'en apercevoir.
Un Architecture Decision Record tient sur une page : le contexte, la décision, les options écartées avec leurs raisons, et les conséquences acceptées. Cela paraît bureaucratique jusqu'au jour où quelqu'un demande pourquoi cette file de messages plutôt qu'une autre, et que les trois personnes présentes à la réunion sont parties.
L'intérêt principal n'est pas l'archive, il est dans l'écriture. Rédiger les options écartées oblige à les avoir considérées. Nous avons vu plusieurs décisions changer pendant la rédaction de leur propre ADR, simplement parce que mettre les raisons noir sur blanc a montré qu'elles ne tenaient pas.
Le modèle C4 propose quatre niveaux de zoom. Dans la pratique deux suffisent : le contexte, qui montre le système et ce qui l'entoure, et les conteneurs, qui montrent les applications, les bases et les files. Les niveaux plus fins se périment en quelques semaines, personne ne les met à jour, et ils finissent par mentir.
Un schéma faux est pire qu'un schéma absent. Le second oblige à aller lire le code ; le premier envoie confiant dans la mauvaise direction. C'est pour cette raison que nous en produisons peu et que nous les tenons à jour, plutôt que de livrer une documentation impressionnante le premier mois.
Un écran mal conçu se refait en deux jours. Un modèle de données mal conçu se traîne pendant des années, parce qu'il faut migrer l'existant à chaque correction. Nous établissons donc le modèle en premier, en confrontant chaque entité au vocabulaire réel des utilisateurs plutôt qu'à celui du cahier des charges.
Ce travail fait ressortir les ambiguïtés que le langage courant masque. Un « dossier » ne désigne pas la même chose au commercial et à l'administratif dans la plupart des organisations que nous avons vues, et le découvrir au moment de la reprise des données coûte infiniment plus cher qu'une heure de discussion au bon moment.
Nous avons produit des documents d'architecture de trente pages que personne n'a rouverts, y compris nous. Le volume donnait le sentiment du travail bien fait et masquait le fait que les décisions difficiles n'y étaient pas tranchées. Une page qui tranche vaut mieux que trente qui décrivent, et c'est une leçon que nous avons apprise en la payant.
Écrit au passé, parce que nous y sommes passés.
Sprints courts avec démos, pair programming, revues de code obligatoires, commits atomiques.
Les itérations courtes ne servent pas à aller plus vite. Elles servent à se tromper moins longtemps. Deux semaines, c'est le délai au bout duquel une erreur de compréhension coûte encore peu à corriger ; à trois mois, elle a contaminé le reste et se défend au lieu de se corriger.
La démonstration de fin d'itération a lieu même quand il n'y a rien de réjouissant à montrer. Ce sont celles-là qui comptent : une démonstration où l'on explique pourquoi une piste a été abandonnée apporte plus qu'une démonstration où tout fonctionne, parce qu'elle porte l'information que personne n'aurait donnée spontanément.
Une revue qui commente le formatage est du temps perdu, et le formatage devrait être automatique de toute façon. Une revue utile pose trois questions : est-ce que cela résout le bon problème, est-ce que quelqu'un d'autre pourra le reprendre dans six mois, et qu'est-ce qui casse si cette hypothèse est fausse.
Nous imposons la revue avant fusion, sans exception et y compris entre nous. L'exception « c'est urgent » est exactement le cas où la revue rapporte le plus, parce que c'est sous pression qu'on prend les raccourcis qu'on regrette. Une revue coûte vingt minutes ; un correctif d'urgence en production coûte une soirée et de la confiance.
Deux personnes sur un écran de saisie sans règle métier, c'est du gaspillage assumé et nous ne le faisons pas. Deux personnes sur la conception d'un moteur de règles, c'est la moitié du temps de débogage économisé et une deuxième personne qui comprend le système. La bascule se situe là où le problème est difficile, pas là où il est long.
L'effet secondaire compte autant que l'effet direct : le pair programming répartit la connaissance. Sur un projet où une seule personne comprend le cœur du système, son départ ou même ses congés deviennent un risque de calendrier. Nous préférons payer ce risque en heures de binôme plutôt qu'en semaines de reprise.
Un commit doit contenir un changement et un seul, et son message doit dire pourquoi plutôt que quoi. Le quoi est déjà dans le diff. Le pourquoi disparaît avec la personne qui l'a écrit, et c'est exactement ce qu'on cherche deux ans plus tard, à trois heures du matin, en remontant l'historique d'une ligne suspecte.
Cette discipline a une conséquence pratique immédiate : elle rend le retour arrière chirurgical. Annuler un changement précis sans emporter les quatre autres qui l'accompagnaient, c'est la différence entre un incident circonscrit et une régression complète de la journée de travail.
Nous avons laissé passer des itérations sans démonstration, sous prétexte qu'il n'y avait « rien à montrer ». À chaque fois, c'est précisément là que le projet dérivait. L'absence de démonstration n'est jamais un problème de calendrier : c'est le symptôme d'un travail dont personne ne sait plus dire ce qu'il produit.
Écrit au passé, parce que nous y sommes passés.
Tests unitaires, d'intégration et end-to-end. Couverture mesurée, non-régression automatisée.
Les tests ne servent pas à prouver que le logiciel fonctionne, ce qu'aucun test ne peut faire. Ils servent à rendre le changement possible sans peur. Une base sans tests se fige d'elle-même : chacun évite les zones sensibles, les contournements s'accumulent, et le coût du moindre ajout augmente jusqu'à ce que la réécriture paraisse raisonnable.
Nous ne visons donc pas un pourcentage de couverture. Une couverture à 90 % ne dit rien si les 10 % restants sont le calcul de TVA. Un chiffre de couverture mesure ce qui a été exécuté, jamais ce qui a été vérifié, et l'optimiser directement produit des tests qui appellent du code sans rien affirmer.
Les tests unitaires couvrent les règles qui ont un prix en euros quand elles se trompent : un calcul de remise, une éligibilité, une règle de facturation. Ils sont rapides et nombreux. Les tests d'intégration couvrent les frontières, là où ça casse pour de vrai : la base de données, les appels sortants, la sérialisation. Ils sont plus lents et beaucoup moins nombreux.
Au-dessus, quelques parcours de bout en bout : connexion, action principale, paiement s'il y en a un. Cinq parcours bien choisis attrapent plus de régressions que deux cents tests d'interface, et coûtent moins cher à maintenir. Le piège classique est d'en écrire cinquante, de les voir échouer par intermittence, et de finir par tous les désactiver.
Une suite de quinze minutes ne sera pas lancée avant de pousser. Elle sera lancée par l'intégration continue, donc après coup, donc les erreurs seront découvertes en lot et attribuées à personne en particulier. Nous traitons la durée comme une contrainte de conception au même titre que le reste, et nous visons moins de deux minutes en local.
Quand la suite dépasse ce budget, nous la découpons plutôt que de l'accepter : une première passe rapide qui bloque, une seconde plus lente qui informe. C'est le seul moyen que nous connaissions de garder l'habitude de tester avant de pousser, et cette habitude vaut plus que n'importe quel outil.
Certaines classes de défauts ne se détectent pas par exécution : une dépendance avec une faille connue, un secret laissé dans le code, une complexité qui a doublé sans que personne ne l'ait décidé. Ces contrôles tournent à chaque intégration et échouent la construction plutôt que d'émettre un avertissement, parce qu'un avertissement récurrent finit toujours par être ignoré.
Nous réglons les seuils au démarrage du projet et nous ne les relâchons pas en cours de route. Desserrer un seuil pour faire passer une livraison pressée est la manière la plus courante de perdre l'outil : une fois qu'il a été contourné, plus personne ne lui fait confiance.
Nous avons couru après un chiffre de couverture sur un projet, et nous l'avons obtenu. Les tests appelaient le code sans rien affirmer, la couverture était superbe, et les bugs sortaient en production exactement au même rythme. Depuis, nous ne mesurons plus la couverture comme un objectif mais comme un indice, et nous regardons ce que les tests affirment.
Écrit au passé, parce que nous y sommes passés.
Pipelines CI/CD, environnements éphémères, déploiements traçables, monitoring et alerting.
Le critère de réussite d'une mise en production n'est pas technique. C'est qu'un développeur arrivé depuis trois semaines livre un mardi après-midi, seul, sans demander l'autorisation à personne. Tant que ce n'est pas vrai, la chaîne existe mais le problème demeure : les livraisons restent un événement, donc elles sont rares, donc elles sont grosses, donc elles font peur.
Tout ce que nous mettons en place sert cet objectif unique. Rien de ce qui suit n'est un but en soi, et nous écartons volontiers un outil séduisant qui n'y contribue pas.
Une chaîne qui prend vingt-cinq minutes n'est pas lancée à chaque changement. Les changements s'accumulent, les livraisons grossissent, le risque par livraison augmente, et la peur qu'elles inspirent justifie de livrer encore moins souvent. C'est un cercle, et on ne le casse pas par le haut en ajoutant des validations.
On le casse par le bas, en descendant sous les dix minutes, quitte à découper la chaîne en étapes dont seule la première bloque. Le reste tourne en arrière-plan et informe. Ce seul chiffre change davantage le comportement d'une équipe que n'importe quel discours sur la qualité.
Un environnement configuré à la main devient irremplaçable en six mois, et personne ne sait plus ce qui y a été modifié ni pourquoi. Nous les décrivons donc en code, et nous les détruisons régulièrement pour vérifier qu'ils se reconstruisent. Un environnement qu'on n'a jamais osé détruire n'est pas reproductible, il est seulement encore debout.
L'environnement éphémère par branche est l'application directe de ce principe : chaque proposition de changement obtient sa propre instance, avec ses données de test, que l'on peut ouvrir et montrer. Cela transforme la revue, qui cesse d'être une lecture de code pour devenir un essai réel.
Un déploiement qui ne peut pas être annulé n'est pas un déploiement, c'est un pari. Nous exigeons un retour arrière en une commande, et nous le testons, parce qu'un mécanisme de secours jamais essayé échoue au premier usage réel — c'est-à-dire au pire moment possible.
Les drapeaux de fonctionnalité complètent le dispositif en séparant deux choses qu'on confond souvent : livrer du code et activer une fonctionnalité. Le code part en production éteint, on l'allume quand on veut, pour qui on veut, et on l'éteint sans redéployer si quelque chose se passe mal.
Nous avons livré des chaînes de déploiement techniquement irréprochables que l'équipe n'a jamais utilisées, parce qu'elle n'avait pas été associée à leur construction. Une chaîne qu'on découvre à la fin est une chaîne que personne ne sait réparer au premier incident, et qui sera contournée au second. Nous la construisons désormais avec les personnes qui vont l'exploiter, dans leurs outils.
Écrit au passé, parce que nous y sommes passés.
Support récurrent, correctifs, évolutions produit et transfert de compétences à vos équipes.
Cette étape n'a pas de fin, et c'est ce qui la rend différente des cinq précédentes. Un logiciel en production change parce que le monde autour de lui change : une réglementation, un partenaire, une version de système, un usage que personne n'avait prévu. Le maintenir n'est pas le réparer, c'est le suivre.
Notre objectif déclaré, et nous le disons dès le premier jour, est de devenir inutiles. Une prestation d'accompagnement qui augmente la dépendance de votre équipe a échoué, même si tout le monde en est content sur le moment. C'est un critère inconfortable pour un prestataire, et c'est le seul honnête.
Livrer une documentation et considérer le transfert fait est une illusion confortable. Personne n'apprend un système en lisant sa documentation ; on l'apprend en le modifiant sous le regard de quelqu'un qui le connaît. Nous organisons donc le transfert comme du travail réel : vos développeurs prennent des tickets, nous relisons, et nous nous retirons progressivement.
La mesure du transfert est simple et vérifiable : le délai au bout duquel votre équipe livre une évolution sans nous. Tant que ce délai ne baisse pas, la documentation ne sert à rien, quelle que soit son épaisseur.
Nous ne maintenons que la documentation dont l'absence bloquerait quelqu'un : comment démarrer le projet, comment déployer, comment diagnostiquer les pannes courantes, et les ADR. Tout le reste est mieux servi par le code lui-même et par des tests lisibles, qui ont l'avantage d'être faux bruyamment quand ils se périment.
Une documentation qui décrit le fonctionnement interne se désynchronise en quelques semaines et devient un piège. Nous préférons en avoir peu et la savoir juste, plutôt que beaucoup et devoir vérifier chaque page avant de s'y fier.
La dette n'est pas un défaut moral, c'est un emprunt : parfois raisonnable, toujours à rembourser. Le problème n'est pas de l'avoir contractée mais de ne pas savoir combien on doit. Nous tenons donc une liste courte et chiffrée de ce qui coûte réellement à chaque évolution, et elle est discutée avec vous.
Cette liste est délibérément courte. Une dette de deux cents lignes n'est pas un inventaire, c'est un aveu qu'on ne priorise plus. Nous préférons cinq entrées dont on connaît le coût et qu'on traite, à un registre exhaustif que personne n'ouvre.
Nous avons entretenu, sans le vouloir, des dépendances confortables : répondre vite à chaque demande plutôt que de montrer comment faire, parce que c'était plus rapide sur le moment et apprécié. Au bout de deux ans, l'équipe cliente n'avait pas progressé et nous étions devenus indispensables. C'est un échec, même quand il se facture bien.
Écrit au passé, parce que nous y sommes passés.
Les règles que nous appliquons par défaut. Elles se discutent projet par projet, mais il faut une raison pour s'en écarter, pas une raison pour les suivre.
Ce que nous employons quand rien ne l'impose. Si vous êtes déjà sur GitLab, Azure DevOps ou une autre chaîne, nous travaillons avec la vôtre plutôt que d'imposer un déménagement.
Dites-nous ce que vous cherchez à construire ou à reprendre. Réponse sous 24 heures ouvrées, sans engagement, et un avis franc sur la faisabilité même si la réponse ne nous arrange pas.
