Essai · 13 mai 2026

Nous avons appris les bonnes méthodes. Puis nous avons appris à les contourner.

Quand on se forme comme développeur, on nous enseigne des choses très saines. On nous parle de besoins utilisateurs, d’entrevues avec des experts de domaine, de spécifications, d’analyses fonctionnelles, de flux de données, de modèles de données, d’architecture, de diagrammes, de machines à états, de cas d’utilisation, de stratégies de test. Toute cette formation repose sur une idée simple : un bon système logiciel ne devrait pas sortir de nulle part. Il devrait naître d’une compréhension claire du réel.

Sur le plan intellectuel, tout cela est juste. Et pourtant, dans la vraie vie, ce n’est pas toujours ainsi que les choses se passent.

Dans beaucoup d’équipes, on démarre avec quelques échanges avec le client, quelques exemples concrets, une liste de besoins. Les spécifications deviennent parfois une simple liste d’épicerie. Les diagrammes existent, mais rarement de façon exhaustive. Les décisions d’architecture sont prises, mais pas toujours formalisées. Ce n’est pas nécessairement de la négligence. C’est souvent un compromis entre le temps, la pression, la vélocité et la confiance accordée à l’expérience des développeurs en place.

Avec les années, on finit par devenir très bon dans cette économie implicite. On fusionne les rôles. On devient programmeur-analyste, ou analyste-programmeur, selon le mot qu’on préfère. On développe un instinct. On sait où mettre une frontière. On sait quand serrer une API. Une part énorme de cette compétence cesse d’être visible parce qu’elle vit dans notre tête. Cette invisibilité a longtemps été compatible avec une excellente productivité.

L’illusion du prompt suffisant, puis le plafond de verre

Puis l’IA de codage est arrivée dans nos IDE, et une première phase très excitante a commencé.

Au début, l’illusion était presque parfaite. On demandait une méthode, un service, un endpoint, un composant. L’outil complétait du code, proposait des tests, suggérait des refactorings. Et cela marchait vraiment. Ce qui fonctionnait à ce moment-là, ce n’était pas seulement l’IA. C’était surtout le fait que le contexte restait dans la tête du développeur. L’architecture, l’historique produit, les contraintes métier, les décisions prises avec un client six mois plus tôt — tout cela vivait dans ma tête, et l’IA opérait dans l’espace que je bornais moi-même à chaque instant.

Quelques mois plus tard, j’ai commencé à vouloir déléguer davantage. Pas seulement des fragments de code, mais des ensembles plus consistants. Et là, le plafond de verre est apparu. L’IA se heurtait rapidement à ce qui n’était nulle part : les raisons derrière les décisions, les contraintes implicites, les choix d’architecture, l’historique des compromis. Je devais la recadrer, lui rappeler des règles, corriger des hypothèses. Pire encore, tout cela défilait dans les chats. Une conversation chasse l’autre. Un arbitrage important a existé, mais il s’est dissous dans le flot d’interactions.

Des notes aux plans : le début du context engineering

Ma première réaction a été triviale, mais structurante : j’ai commencé à lui faire prendre des notes. Pas pour faire joli. Pas pour satisfaire un principe documentaire abstrait. Juste pour ne pas perdre les clarifications, les raisonnements et les décisions prises en cours de route.

Après quelques mois, cela a évolué vers des plans plus explicites. On a commencé à parler de context engineering. J’ai préféré rester léger : faire des plans, les conserver dans le dépôt, les clore proprement, les archiver. Cette approche légère a bien fonctionné. Mais elle a aussi révélé une nouvelle exigence : faire des plans ne suffit pas si ces plans réinventent à chaque fois une analyse qui aurait dû exister de façon plus stable.

2026 : de meilleurs modèles exigent de meilleures spécifications

Le vrai tournant s’est produit au début de 2026.

Les modèles sont devenus plus autonomes, plus proactifs, plus capables d’enchaîner eux-mêmes des étapes de travail. Et un paradoxe est apparu : plus ils devenaient puissants, plus ils exigeaient une meilleure alimentation en contexte. Pour obtenir un meilleur code, il ne suffisait plus de mieux prompter. Il fallait mieux analyser, mieux découper, mieux concevoir, mieux documenter.

J’ai remarqué quelque chose de frappant : les modèles récents proposaient eux-mêmes d’ajouter des étapes de spécification. Ils demandaient davantage de précision, davantage de contraintes, davantage de structure. L’industrie IA elle-même semblait redécouvrir ce que le développement logiciel sait depuis des décennies : la qualité d’un système dépend aussi de la qualité des artefacts qui précèdent le code.

Cela m’a obligé à regarder un biais très personnel en face. Comme beaucoup de développeurs expérimentés, j’avais pris l’habitude de capitaliser sur mon expérience pour comprimer l’analyse dans ma tête. Je pouvais passer directement d’un besoin à une implémentation raisonnable parce que les user stories, les tableaux de décision, les flux fonctionnels, tout cela vivait déjà mentalement chez moi. L’IA a mis ce raccourci en crise. Non pas parce qu’elle est incapable, mais parce qu’elle ne bénéficie pas de cette mémoire implicite tant qu’on ne l’externalise pas.

Le vrai retour aux sources

À partir de là, le constat s’est imposé : le spec-first n’est pas un effet de mode. C’est un retour aux fondations.

Si je veux vraiment collaborer avec l’IA, je dois recommencer à faire explicitement ce que j’avais fini par faire mentalement. Définir l’intention produit. Clarifier la réalité opérationnelle. Établir les objectifs. Poser les contraintes. Choisir la stack en connaissance de cause. Décrire l’architecture. Nommer les frontières. Documenter les flux fonctionnels. Expliquer les décisions de conception. Prévoir la stratégie de test. Rien de tout cela n’est nouveau. La nouveauté, c’est l’incitatif.

Pendant des décennies, beaucoup de documentation a fini par être perçue comme un vœu pieux. Quelque chose qu’on devrait maintenir, mais qui coûte cher, qui se dégrade vite, et qui freine la livraison si elle devient trop lourde. Avec l’IA, cette dynamique change profondément. La documentation bien faite cesse d’être seulement une dette morale de l’équipe. Elle devient un multiplicateur de vélocité. Elle devient vivante parce qu’elle nourrit directement un partenaire de travail qui sait lire, comparer, proposer, challenger, écrire, tester et naviguer entre plusieurs couches du système.

Le parcours de l’IA a évolué aussi : naissance d’une ségrégation

Il y a quelque chose d’important qu’on n’énonce pas assez clairement : le parcours de l’IA elle-même a évolué. Et cette évolution engendre une ségrégation intellectuelle forte au sein de la profession.

D’un côté, il y a ceux qui ont adopté la discipline de l’analyse. Les diagrammes de séquence, les machines à états finis, les tables de décision, les flux fonctionnels. Ces gens sont devenus des analystes au sens fort du terme, et l’IA est devenue leur programmeur. Ils lui livrent des spécifications précises, structurées, actionnables — et elle produit du code cohérent, testé, aligné sur une vision. De l’autre côté, il y a ceux qui ont continué dans le mode prompt-et-codage, plus ou moins sophistiqué, mais sans rehausser leur discipline d’analyse. L’écart entre les deux groupes se creuse rapidement.

Un informaticien, au fond, fait quelque chose de simple : il découvre un monde, s’y intéresse, définit un produit, puis mobilise des outils d’analyse, de conception et d’architecture pour lui donner forme. Ce que l’IA a changé, c’est que la partie « donner forme » peut désormais être très largement déléguée. Ce qui reste irremplçablement humain, c’est la partie « comprendre, définir, structurer, décider ».

L’inconfort partagé : malaise, humilité et faux espoirs

Beaucoup d’équipes sentent intuitivement qu’un retour aux sources s’impose. Elles comprennent que l’analyse, la conception et l’architecture doivent revenir au premier plan. Mais cette intuition s’accompagne souvent d’un malaise. Les gens savent qu’il manque quelque chose, sans savoir exactement comment le remettre en place.

J’ai vu des équipes se demander quelle forme documentaire adopter, quel niveau de détail viser, comment éviter de produire des documents inutiles, et surtout comment ne pas commettre une erreur méthodologique. Cette peur de mal faire produit un effet paradoxal : au lieu de remettre les choses en mouvement, elle encourage l’immobilisme. On attend un signal fort venu des pairs, des grands fournisseurs, des cabinets de conseil. Ce signal n’arrive jamais de façon nette. Pendant ce temps-là, les équipes font du surplace en croyant être prudentes.

Il y a aussi une dimension plus inconfortable, mais essentielle. Pour des développeurs avec dix, quinze ou vingt ans d’expérience, il est difficile d’accepter qu’ils ne sont peut-être pas aussi solides qu’ils le pensaient sur certains fondamentaux. Je le dis aussi contre moi-même. Dans mon propre projet, j’ai créé de la dette très vite. La première ébauche avait été produite dans une phase de vibe coding pur et dur : des niveaux mélangés, des services et des accès DAO dans les contrôleurs, des séparations floues. C’était objectivement laid. Ce moment m’a forcé à un constat désagréable : je n’étais pas en train d’appliquer proprement l’analyse et la conception que je pensais pourtant maîtriser.

Dans cet état d’hésitation, un autre réflexe apparaît souvent : l’espoir qu’un framework, un outil ou un mode du moment va résoudre le problème à notre place. Hier on était en mode Copilot. Aujourd’hui tout le monde parle de Claude Code. Demain ce sera autre chose. Je ne crois pas à cette magie. Changer d’outil peut améliorer certaines choses, mais rien de cela ne corrige le problème fondamental si l’équipe n’a pas reconnecté avec son rôle de fond : analyste, concepteur, architecte, testeur, expert de domaine, et pas seulement producteur de code.

Ne pas choisir une méthode légère, c’est choisir l’immobilisme

La bonne nouvelle, c’est qu’il n’est pas nécessaire de revenir aux lourdeurs méthodologiques d’hier.

Le parallèle avec l’architecture logicielle me paraît éclairant. Pendant quelques années, les microservices ont été vendus comme une panacée. On a vu la suite : explosion de complexité opérationnelle, de maintenance et d’interfaces fragiles. Le marché n’est pas revenu au monolithe par nostalgie. Il est revenu au monolithe modulaire parce qu’il cherchait un meilleur point d’équilibre. Il faut faire exactement la même chose avec la méthodologie IA.

Il faut aussi éviter le réflexe RUP. Les grandes méthodologies qui prétendent tout couvrir — Rational Unified Process et ses monstres de templates — se sont effondrées sur elles-mêmes : trop lourd, trop rigide, trop éloigné de la réalité des projets. Ce qui devrait exister à la place, c’est une méthodologie propre au projet : légère, pragmatique, choisie délibérément. À mes yeux, le choix le plus structurant est simple : décider qu’une part de la méthode doit vivre à même la base de code, dans des formats simples, versionnés, lisibles par les humains et par l’IA.

De l’analyste qui choisit une méthode au méthodologiste qui la conçoit

C’est ici que quelque chose de fondamental m’a été révélé.

J’avais une approche d’analyste-programmeur. J’avais à cœur l’architecture du système, j’avais une bonne expérience, j’utilisais l’IA en mode plan. J’interagissais avec elle pour créer des analyses, des concepts, des tables de décision. Mais il me manquait une véritable méthodologie. Ce que je faisais était bon, mais c’était artisanal. Chaque plan, chaque artefact, chaque forme documentaire était réinventé en chemin.

Un ami m’a présenté sa façon de travailler, qui avait consisté très tôt dans son projet à rédiger des templates, une méthodologie pour les utiliser, et des skills — au sens moderne de l’IA : des instructions spécialisées, des agents à rôle défini, des séquences d’analyse formalisées. Ces templates, ce guide méthodologique et ces skills forment un système. Résultat : une fois cette méthodologie rodée, tout est devenu uniforme, systématique, répétable. Le travail s’est accéléré. Il est devenu rigoureux, fiable.

Ce qui m’a frappé, c’est la différence de niveau. Il y a l’analyste qui UTILISE une méthode. Et il y a le méthodologiste qui CONÇOIT la méthode adaptée au projet. Le méthodologiste prend comme objet de premier plan non pas le produit, non pas une architecture ou un concept, mais les guides qui orientent eux-mêmes ces activités. Ce sont ces métadécisions qui forment le cadre dans lequel l’analyste, le concepteur et l’IA travaillent ensuite.

Cette découverte m’a propulsé dans un grand chantier de retrofitting : reprendre la matière produite jusqu’ici — à format variable, à profondeur variable — et la réinjecter vers un format méthodologisé et uniforme. Des templates, des patterns, des conventions de nommage, des cycles, des phases. Il y aura du travail, mais c’est la bonne direction.

La grande leçon à tirer de tout ceci, je l’ai visualisée en trois niveaux :

Avant l’IA, l’analyste-programmeur opérait aux deux niveaux du bas. Maintenant, l’IA occupe le niveau du bas avec une compétence croissante. Ce qui reste irremplçablement humain, c’est ce qui se passe aux deux niveaux supérieurs. L’humain doit désormais être un visionnaire-méthodologiste capable de définir des visions, de concevoir des méthodologies appropriées, d’orchestrer des analyses, de poser des architectures — et l’IA produit le code. Ce n’est pas un affaiblissement du rôle du développeur. C’est une élévation.

Les outils qui incarnent cette approche : exemples, pas finalités

L’écosystème ne s’est pas arrêté à la théorie. Des outils ont commencé à matérialiser cette élévation méthodologique de façon concrète. Claude Code, qui s’est imposé comme un des environnements les plus populaires du moment, en est un exemple frappant. Avec des extensions comme Super Powers, il dépasse largement le mode plan ordinaire pour offrir une structure méthodologique directement intégrée : des workflows interactifs, une organisation standardisée des artefacts, une façon de guider l’agent qui rappelle davantage l’interaction avec un partenaire d’analyse qu’avec un simple générateur de code.

Mais c’est là qu’il faut résister à un réflexe familier : celui de voir dans une solution populaire la solution définitive. Claude Code et Super Powers sont des exemples à étudier, des points de départ à adapter — pas une norme à copier tel quel. Ce qui fait la force de cette approche n’est pas liée à un outil particulier. Elle tient à un principe : un agent IA est capable d’interagir à un niveau méthodologique avec quiconque veut bien organiser son travail à ce niveau.

La customisation méthodologique doit être prudente. On ne restructure pas son workflow à chaque nouvelle mode. Mais elle apporte des avantages réels quand elle est faite avec discernement. Une équipe qui développe une plateforme de sécurité n’a pas la même palette d’outils d’analyse qu’une équipe qui construit un produit SaaS de gestion de contenu. La méthodologie doit refléter cette réalité.

La dette qu’on ne veut pas regarder en face

Dans beaucoup d’organisations, ce qui est valorisé, c’est d’avancer la business. C’est normal jusqu’à un certain point. Mais cette logique a un angle mort : le reverse engineering, la reconstruction documentaire, l’hygiène de code ne paraîssent presque jamais de façon flatteuse dans un état d’avancement. Quand on rattrape des mois de laisser-aller technique, on ne donne pas l’impression d’inventer une nouvelle fonctionnalité spectaculaire. Et pourtant, sans cette étape, les bénéfices de l’IA ne se multiplient pas correctement.

Dans mon cas, j’ai fini par faire un moratoire de plusieurs semaines pour remettre le code comme du monde. Ajouter de la Javadoc. Nettoyer les warnings. Introduire des garde-fous de qualité. Durcir les conventions. C’est après cette remise en état que les bénéfices multiplicateurs de l’IA ont commencé à mieux se cumuler.

Dans un brownfield, ce rattrapage peut exiger de ralentir franchement la livraison de nouvelles choses pour reconstituer les conditions qui rendront ensuite la vélocité durable. Il faut accepter que ce travail ressemble parfois à un repli stratégique : on s’arrête, on se regarde honnêtement, on nomme la dette, on rétablit des bases plus saines, puis on repart avec une autre qualité d’élan.

Documents, templates, skills : une structure qui vit dans le dépôt

Pour se remettre en mouvement, il faut assumer trois familles d’artefacts directement dans le dépôt.

La première famille, ce sont les plans de travail. Des plans avec une structure minimale, des garde-fous, un statut, un historique, et la possibilité d’être relus, critiqués, amendés, puis archivés. Ces plans deviennent un espace d’interaction entre analystes, concepteurs, développeurs et IA. Si l’on veut une véritable vélocité collective, il faut commencer à versionner les plans de travail au lieu de les laisser se dissoudre dans des chats ou des réunions.

La deuxième famille, ce sont les documents qui décrivent la vérité actuelle du système. Pas en prose abstraite. Une structure parallèle au code, qui en reflète l’organisation et les frontières principales. Des documents d’architecture, de features, de frontières et de mappings. Des flux fonctionnels, des décisions de conception, des contrats d’interface. Quand cette structure existe, elle devient lisible par un humain sans replonger immédiatement dans le code, et exploitable par l’IA comme contexte de génération et de vérification.

La troisième famille, ce sont les templates et les skills. Des templates qui donnent une forme attendue aux artefacts d’analyse et de prise de décision. Des skills IA qui implémentent des patterns spécifiques : un skill pour produire une analyse de fonctionnalité, un skill pour modéliser une machine à états, un skill pour conduire une revue d’architecture. Ces templates et skills forment le cœur vivant de la méthodologie. Ils rendent le travail systématique et reproductible, pas seulement documenté.

Il y a aussi un accélérateur sous-évalué dans ce dispositif : la dictée. Pour produire du contexte de qualité, il faut pouvoir communiquer massivement — verbaliser des nuances, des raisons, des contraintes, des arbitrages. En 2026, je ne crois plus qu’on puisse soutenir ce volume d’élaboration uniquement au clavier. La parole fluide libère une pensée plus riche, moins autocensurée, plus rapide à déposer. On n’économise plus les mots. Ensuite, l’IA aide à trier, condenser, reformuler.

Greenfield ou brownfield, la logique est la même

Dans un projet greenfield, tout cela est relativement simple. On peut mettre en place la structure documentaire, les templates et les skills dès le départ et les faire grandir en parallèle du code.

Dans un brownfield, c’est plus difficile. Il faut une phase de reverse engineering. Il faut choisir les modules les plus critiques, ramener dans les documents l’essentiel des frontières, des mappings, des interactions et des décisions implicites. C’est un transvasement progressif de l’information qui vit encore dans la tête des développeurs vers une structure documentaire plus stable. Mais ce transvasement ne fonctionne pas très bien si l’équipe refuse de regarder sa dette en face. Se remettre en mouvement commence justement par le choix d’une structure assez simple pour être adoptée et assez utile pour devenir vivante.

L’IA à tous les niveaux, jusqu’au comportement d’ingénieur

L’IA n’est pas seulement un outil de génération de code. Elle devient utile à tous les étages. Elle peut participer au brainstorming produit. Elle peut challenger un positionnement. Elle peut aider à raffiner une architecture. Elle peut reformuler des exigences. Elle peut pointer les zones floues d’un workflow. Elle peut proposer une stratégie de test raisonnable. Elle peut ensuite faire du pair programming très concret sur le code lui-même.

Ce qui m’a le plus frappé récemment, c’est un glissement subtil mais décisif. Avec les mêmes scripts, les mêmes documents, les mêmes conventions, un modèle plus récent s’est mis à prendre des initiatives que je n’avais pas explicitement demandées. Pour valider une évolution touchant à la fois l’interface et la base de données, l’agent a constaté qu’il disposait des scripts, des repères de test, des accès à l’Admin UI et d’un environnement de démonstration déjà documenté dans le dépôt. Il a compris qu’il devait ouvrir un navigateur, se connecter, utiliser le Demo Device prévu par le bootstrap, générer les bonnes données et vérifier le scénario de bout en bout.

L’autonomie de l’IA ne vient pas seulement de ses progrès internes. Elle vient aussi de la qualité du monde documentaire et opérationnel dans lequel on l’insère.

Le développeur n’est plus celui qui garde tout dans sa tête

Pendant très longtemps, la figure implicite du développeur héroïque a dominé : celui qui comprend tout, qui se souvient de tout, qui porte l’architecture, la logique métier, la dette historique, les exceptions et les règles non écrites dans sa propre tête. Cette figure n’a pas disparu, mais elle perd son avantage central. Ce qui devient stratégique, ce n’est plus de garder l’information en soi. C’est de savoir la structurer, l’écrire, l’articuler, la rendre exploitable par d’autres humains et par l’IA.

Le développeur que cette période favorise est celui qui sait comprendre le produit, comprendre le client, comprendre les contraintes, comprendre l’architecture, faire des choix de conception, documenter ces choix, et ensuite faire travailler l’IA dans ce cadre. Pas seulement pour coder plus vite. Pour concevoir plus juste, tester plus intelligemment, et conserver un système plus explicable.

Et cela demande souvent un geste plus exigeant qu’on ne l’admet volontiers : accepter de se déplacer vers des niveaux de pensée plus abstraits, reconnaître qu’on a laissé rouiller certaines parties de notre métier, et remettre délibérément de la rigueur là où l’habitude et la vitesse avaient fini par tout comprimer dans notre tête.

Conclusion

English : English version of this article

Voir aussi : Du code à l’intention

Voir aussi : Manifeste sur le codage assisté par IA

Voir aussi : Du monolithe au contrat