Du savoir au vécu

Le moment du méthodologiste

Il y a un écart entre comprendre un principe et le vivre vraiment. Le jour où j’ai endossé le chapeau du méthodologiste pour de vrai, tout a basculé.

Savoir et vivre, ce n’est pas pareil

J’avais regardé les vidéos. J’avais suivi les discussions sur le développement « spec-first », la pensée structurée avant d’écrire du code, la discipline qui consiste à rendre les décisions explicites et traçables. Intellectuellement, j’étais convaincu. Avec enthousiasme, même.

Et puis un développeur que je connais m’a montré comment il travaillait avec l’IA — sans appeler ça une méthodologie, sans lui donner de nom de framework. Il le faisait, tout simplement. Des skills pour orienter l’agent. Des templates pour les artefacts récurrents. Une séparation nette entre idéation, analyse, conception et implémentation. Rien de complexe. Rien de sur-ingénié. Une pratique claire et répétable, c’est tout.

J’ai été soufflé. Pas parce que c’était sophistiqué. Parce que c’était juste. Et parce que j’ai immédiatement reconnu l’écart : j’avais compris le principe. Je ne l’avais jamais vraiment vécu.

Le chapeau qui me manquait

Un article précédent sur ce site trace un chemin que beaucoup de développeurs ont parcouru au cours de la dernière année : utiliser l’IA d’abord comme générateur de code, puis comme analyste, puis progressivement comme partenaire de vision produit. Chaque étape était une élévation réelle. Chacune changeait la nature de la collaboration.

Mais en regardant mon ami, j’ai vu une étape que je n’avais pas nommée. Pas l’analyste. Pas l’architecte. Le méthodologiste — celui qui conçoit et maintient le processus par lequel tous les autres rôles opèrent.

Une fois que je l’ai vu, je ne pouvais plus ne pas le voir. Et dès que j’ai décidé d’endosser ce chapeau, les choses ont commencé à évoluer dans une direction que je n’avais pas anticipée.

Le premier vrai test

Construire la méthodologie était en soi un plaisir. Les skills, les templates, les conventions d’artefacts, les schémas de nommage, les règles de workflow. Chaque pièce s’assembla avec un plaisir intellectuel difficile à décrire. Le design émergea du dialogue — façonné par les vidéos que j’avais vues, ces échanges, et une énorme quantité d’échanges avec mon partenaire IA.

Vint ensuite le vrai test : l’appliquer à une implémentation concrète pour la première fois. Je m’attendais à de la friction — une couche de processus supplémentaire qui ralentirait un travail que je savais déjà faire.

Et, pour être honnête : cette friction a bel et bien existé. Pas pour les mauvaises raisons — mais elle était là. La session de grillage a fait remonter des hypothèses que je n’avais pas formulées. La tracer bullet m’a forcé à définir ce que « fait » voulait dire avant d’écrire une seule ligne. Il y a eu un allongement réel, que j’ai d’abord challenge. Puis accepté. Parce qu’il était légitime.

Mais il s’est produit quelque chose que je n’avais pas anticipé : l’IA, une fois équipée d’une méthodologie explicite, a manifesté une propension naturelle à vouloir en faire plus. Approfondir encore. Structurer davantage. Ajouter une précision supplémentaire. La méthodologie, dans les mains d’un outil statistique avancé — aussi puissant soit-il — pouvait devenir sa propre spirale.

Il m’a fallu exercer un jugement délicat. Pas brusquer l’IA vers l’implémentation : cela aurait annulé le bénéfice de toute la démarche. Mais poser des critères clairs de convergence — à quel point est-on « assez structurés » pour avancer ? Ce recadrage, c’est l’humain qui l’a initié. C’est l’humain qui doit l’initier. L’IA a une propension à générer vite et beaucoup, parfois de façon foisonnante. La qualité que le développeur doit démontrer est de rester neutre : ne pas devenir une chambre d’écho à l’enthousiasme méthodologique de la machine, tout en ne coupant pas les ailes à ce qu’elle apporte de génératif. Établir des critères de convergence explicites entre la vision humaine et la production IA : c’est là que réside le vrai pilotage.

En bout de course, le blitz intake a donné un espace propre à chaque idée parasite qui se serait sinon dissoute dans un fil de conversation. Chaque étape ressemblait moins à une cérémonie qu’à une conversation que j’aurais dû avoir depuis le début. La méthodologie a bien raccourci le chemin — mais il a fallu d’abord traverser ce moment d’équilibriste pour qu’elle tienne sa promesse.

L’allongement était légitime. Ce n’est pas la même chose que d’avoir perdu du temps.

L’IA a adressé exactement mes faiblesses

Je dois dire quelque chose d’honnête ici. Je suis, par nature, quelqu’un qui a du mal avec l’organisation. Nommer les choses de manière cohérente, relier les concepts entre eux, maintenir une documentation structurée — ce sont les bêtes noires de ma carrière. Je produis du code solide et parfois des designs vraiment innovants, mais le chemin peut être long et tortueux. Je me suis frustré moi-même plus souvent que je ne le voudrais admettre.

Ce que j’ai découvert — avec une émotion réelle — c’est que les domaines où l’IA apporte le plus de valeur sont exactement les domaines où je suis le plus faible. Structure. Nommage. Interliage. Maintien de la cohérence dans un corpus d’artefacts qui grandit. Détection des liens que j’aurais oublié de faire. L’IA ne pense pas à ma place. Mais elle convertit systématiquement mes hésitations en interactions productives.

La faiblesse cesse d’être un mur. Elle devient une ouverture de conversation.

Pour quelqu’un qui a passé des décennies silencieusement frustré par sa propre désorganisation, ce n’est pas une chose mineure. C’est une forme de libération. Et je le dis sans exagération.

La méta-méthodologie : enregistrer les décisions sur la méthodologie elle-même

L’un des moments les plus inattendus est venu quand j’ai réalisé que la méthodologie elle-même méritait la même rigueur que j’appliquais au produit.

Nous étions en train d’affiner une convention de nommage lors d’une session de travail — faut-il utiliser un slug ou un numéro séquentiel pour les noms de fichiers d’artefacts. Le raisonnement qui a émergé était clair, délibéré, ancré dans de vrais compromis. Et j’ai pensé : ce raisonnement ne devrait pas disparaître dans un historique de chat. C’est une décision sur notre façon de travailler. Elle mérite un endroit traçable, tout comme n’importe quelle décision architecturale ou produit.

Nous avons donc introduit les décisions méthodologiques — de petits enregistrements du raisonnement derrière les choix de workflow non évidents. Pourquoi une date-plus-slug plutôt qu’un compteur séquentiel. Pourquoi la posture d’itération d’une tracer bullet doit être déclarée avant que le périmètre commence. Pourquoi les cas simples doivent rester simples.

Une méta-méthodologie. Je n’avais imaginé, à aucun moment de ma carrière, que je me trouverais un jour en train de concevoir une telle chose. Et pourtant me voilà, la trouvant franchement passionnante.

La découverte du travail en parallèle

Un autre moment m’a pris par surprise. Travailler sur plusieurs branches, ou sur plusieurs worktrees portant des sujets différents simultanément, crée une catégorie de problèmes de coordination que la méthodologie n’avait pas adressée. Collisions de nommage. Fichiers d’index devenant des points de contention. Deux sessions simultanées pouvant potentiellement entrer en conflit sur le même identifiant séquentiel.

Le problème, une fois nommé, n’était pas difficile à résoudre. Des identifiants date-plus-slug. Des mises à jour d’index différées. Une hypothèse explicite d’orthogonalité des sujets entre branches. Le type de réponse qui semble évident une fois trouvée.

Ce qui m’a frappé, c’est la dynamique : j’ai remarqué la friction, je l’ai nommée, et le raisonnement collaboratif qui a suivi l’a résolu en une seule session. Ni moi seul ni l’IA seule ne serait arrivé là aussi proprement ni aussi vite. L’humain a vu la friction ; l’IA a structuré l’espace de solution ; ensemble nous avons produit quelque chose qu’aucun des deux n’aurait autoré indépendamment.

C’est ce que la méthodologie permet. Pas juste de la structure pour elle-même. Un cadre vivant et ajustable pour une collaboration qui apprend et s’améliore vraiment au fil du temps.

Un paradoxe avec lequel je peux vivre

Je devrais conclure sur une note légèrement paradoxale. J’ai découvert tout cela à cinquante-huit ans, ayant déjà décidé de quitter l’emploi traditionnel. Dans une lecture, le timing est ironique : trouver la pratique de développement la plus puissante de ma carrière juste au moment où je quitte le contexte institutionnel où elle aurait eu la plus grande portée.

Mais j’en suis venu à le voir différemment. Ce que la méthodologie m’a donné n’est pas un avantage professionnel. C’est une clarté de pratique, une sorte de demeure intellectuelle, que je n’avais pas avant. Structurée sans être rigide. Collaborative sans être dépendante. Traçable sans être bureaucratique.

Pour les développeurs qui sont plus tôt dans leur carrière, je peux seulement dire : la combinaison du jugement humain et du partenariat IA, organisée par une méthodologie cohérente, va produire des choses que nous n’avons pas encore pleinement imaginées. L’instinct de retour aux sources était juste. Le principe spec-first était juste. Le chapeau du méthodologiste était la pièce manquante.

Apprendre à le porter a été, en toute franchise, l’un des grands plaisirs intellectuels de ma vie professionnelle.

← En lien : Le retour aux sources du développeur à l’ère de l’IA

← En lien : Du code à l’intention — Un an de workflow avec l’IA