Pair programming avec la MOA : le métier entre dans la boucle

Le pair programming, dans l’imaginaire collectif, c’est deux développeurs devant un écran. Un qui tape, un qui relit. Le second n’est pas là pour taper : il est là pour questionner, et empêcher le premier de foncer dans le mur.

Dans le rituel que je décris ici, le second n’est pas développeur. C’est la MOA.

Et non, elle n’est pas là pour valider du code. Elle arrive avec sa propre IA, le harnais fourni par le dev, et une spec qu’elle a déjà challengée.

Le problème que ça résout

Dans un projet classique, la MOA exprime un besoin. Le dev le traduit en spec. Un agent de codage — piloté par un dev — produit le code. Trois semaines plus tard, on montre l’écran. C’est souvent le premier moment où la MOA voit réellement ce qu’elle a demandé. Et c’est souvent le premier moment où elle comprend que ce n’est pas ça.

Ce n’est pas une question de compétence. C’est une question de distance. Entre le mot et l’écran, il y a trois semaines et une chaîne de traductions. Chaque traduction est une occasion de perdre le sens.

Dans l’article précédent, je décrivais le grill-with-docs comme un préalable à la doc : griller l’idée, fixer le vocabulaire, écrire les ADR. Mais je le pratiquais seul, ou entre devs. Or le vocabulaire, c’est précisément ce que la MOA détient.

Alors j’ai déplacé la chaise. Puis je lui ai donné accès à la mémoire du projet.

La MOA arrive avec sa spec — et son harnais

Premier déplacement : les artefacts du projet ne sont plus réservés aux devs. Le glossaire, les ADR, les specs existantes — tout ce qui dit ce que le projet a décidé, et pourquoi — deviennent la matière première de la MOA.

Elle ne lit pas le code. Elle lit les décisions.

Et elle ne travaille pas dans un chat vide. Elle utilise un harnais : un cadre versionné qui contient les artefacts du projet (glossaire, ADR, specs), un gabarit de spec, une checklist de complétude et des règles explicites. Le harnais dit à l’IA ce qu’elle doit vérifier, ce qu’elle n’a pas le droit de trancher, et quand elle doit poser une question au lieu de combler un trou.

Ce harnais n’est pas un prompt personnel. Il est intégré au dépôt de code, versionné avec le projet, et c’est le dev qui le fournit à la MOA. Elle n’a pas à le construire : elle l’ouvre, elle travaille dedans, et elle signale ce qui manque.

Sans harnais, l’IA de la MOA produit une spec plausible. Avec, elle produit une spec contestable — et c’est exactement ce qu’on veut.

Puis elle donne tout ça à son IA. Pas pour lui demander de coder : pour lui demander de la challenger. « Est-ce que ma demande respecte le vocabulaire ? Est-ce qu’elle contredit un ADR ? Est-ce qu’elle rouvre une décision déjà tranchée ? » Son IA devient un contradicteur métier, nourri par la mémoire du projet.

Puis elle écrit sa spec. En français, avec les mots du projet. Pas un ticket de trois lignes : un document qui dit le quoi, les cas, les exceptions, ce qu’on ne veut pas.

Ce que ça change : la spec arrive déjà relue, déjà confrontée aux décisions existantes. Le dev ne reçoit plus un besoin brut. Il reçoit une proposition.

⚠️ Le piège : la spec de la MOA déborde sur le comment. Son IA propose une architecture, une librairie, un cache. Ce n’est pas son rôle. La règle est simple : la MOA décrit le quoi, le dev arbitre le comment.

👉 Une spec écrite par la MOA avec son IA n’est pas une spec technique. C’est une spec métier, dans le vocabulaire du projet.

Le grill-with-docs se fait à deux

La spec arrive ensuite dans l’IA de codage. Et là, deuxième grill.

Le premier a vérifié que la spec tient debout dans le métier. Le second vérifie qu’elle tient debout dans le code : les impacts, les contradictions avec l’existant, les cas limites, les données manquantes, les régressions possibles. L’IA de codage n’a pas peur de contredire la spec — c’est même ce qu’on lui demande.

La MOA répond. Le dev traduit, challenge la faisabilité et tient le dépôt. L’IA de codage questionne et propose. Personne ne fait le travail de l’autre.

Tout ça se passe à deux, pas à huit. Le grill n’est pas une réunion : c’est un interrogatoire, avec deux IA et deux humains.

Rôle	Ce qu’il apporte	Ce qu’il ne fait pas
MOA	les cas réels, les exceptions, l’arbitrage métier	lire le code, choisir une librairie, valider un diff
IA de la MOA	la confrontation de la spec aux ADR, au glossaire et au gabarit	décider à la place de la MOA
Dev	la traduction, la faisabilité, la tenue du dépôt et du harnais	décider du besoin à la place de la MOA
IA de codage	les impacts, les contradictions, les cas limites	trancher

Le moment le plus utile est souvent le plus inconfortable : quand l’IA de codage demande « et si ? » et que la MOA découvre qu’elle n’avait pas tranché. Ce n’est pas un échec du grill. C’est sa raison d’être.

Exemple typique, sur un écran de programmation travaux. La MOA dit : « on affiche les travaux programmés. » L’IA de codage demande : programmé par qui, à quelle date, et est-ce que ça inclut les travaux reportés ? Trois questions, trois réponses différentes selon les services. En dix minutes, on découvre que le mot recouvre trois réalités.

Et on écrit tout de suite :

Programmé — travaux inscrits au planning pluriannuel avec une date prévisionnelle validée. Avoid : planifié, prévu

Cette ligne, c’est la MOA qui la dicte. Le dev la met en forme. L’IA de codage la relira à chaque session — et ne pourra plus écrire « planifié » à la place.

👉 Le grill ne produit pas un compte rendu. Il produit du vocabulaire et des décisions, versionnés avec le code.

L’implémentation en direct : ce que la MOA regarde

Vient le moment où l’on code. En direct, devant la MOA.

Ce qu’elle voit n’est pas un diff. C’est une boucle.

L’IA de codage écrit le code depuis la spec et le glossaire.
Les tests passent au rouge, puis au vert.
La QA tourne : lint, analyse statique, tests.
Le dev relit, corrige, relance.
L’écran se remplit.

La MOA ne juge pas la qualité du code. Elle n’a pas à le faire. Elle juge trois choses : est-ce que le comportement annoncé est le bon, est-ce que les mots à l’écran sont les siens, est-ce qu’il manque un cas qu’elle connaît.

Et pendant que la boucle tourne, elle peut répondre aux questions qui surgissent. C’est là que le pair programming prend tout son sens : la question ne poireaute pas dans une boîte mail. Elle est tranchée à l’instant où elle apparaît.

⚠️ Le piège, c’est de croire que la boucle est une preuve. Un test vert prouve que le code fait ce que le test dit. Pas que le besoin est couvert.

La vérification visuelle et la mini-recette

Une fois l’écran debout, on ne commite pas. On regarde.

La MOA clique. Elle fait le cas nominal, puis le cas tordu qu’elle connaît et que personne n’a écrit. Elle vérifie les libellés, l’ordre des champs, les droits, ce qui se passe quand la donnée manque.

La mini-recette tient en dix à quinze minutes et en trois à cinq scénarios. Pas plus. C’est un garde-fou, pas une campagne de tests.

Ce qu’elle attrape : le besoin mal compris, le mot approximatif, le cas oublié, l’écran qui ne ressemble pas au métier.

Ce qu’elle n’attrape pas : la volumétrie, la performance, les régressions, l’intégration avec les autres briques, les données sales.

👉 La mini-recette n’est pas la recette. C’est ce qui empêche de pousser une évidence fausse en homologation.

Le commit est une signature

Quand la mini-recette est validée, l’IA de codage s’arrête. Le dev relit le diff, relance la QA, et commite. À la main.

Pas parce qu’un agent ne saurait pas taper git commit. Parce qu’un commit est un engagement : « ce que je pousse est relu, testé, et je peux le défaire ». Cette phrase-là, un agent ne peut pas la signer. Il ne porte pas la responsabilité.

Le commit part ensuite en homologation. Et là, la recette est plus profonde : données réelles, utilisateurs réels, volumétrie réelle. C’est un autre exercice, et il reste non négociable.

🎯 La mini-recette protège l’homologation des erreurs grossières. L’homologation protège la production des erreurs de contexte.

Ce que ça change pour vous, MOA

Avant	Après
Vous arrivez avec un besoin flou	Vous arrivez avec une spec écrite et challengée
Vous utilisez un chatbot générique	Vous travaillez dans un harnais fourni par le dev
Votre spec est retraduite par le dev	Votre spec est confrontée au code par l’IA de codage
Vous découvrez les ADR à la recette	Vous les donnez à votre IA pour challenger vos demandes
Vous découvrez l’écran à la recette	Vous découvrez l’écran pendant qu’on le construit
Vous validez ce qu’on vous montre	Vous arbitrez ce que vous avez demandé
Le commit est un geste technique	Le commit est une signature humaine

Ce que ça exige de vous :

une heure de disponibilité au bon moment, pas une journée
la capacité de dire « je ne sais pas » devant l’IA — c’est une réponse utile, pas une faiblesse
l’acceptation de ne pas valider du code : vous validez un comportement
la présence d’un vrai expert métier, pas d’un intermédiaire qui répète ce qu’on lui a dit
la discipline de relire la spec que votre IA a écrite : elle propose, vous signez
la discipline d’utiliser le harnais fourni par le dev, et de signaler ce qui manque
l’arbitrage quand votre IA et celle du dev ne sont pas d’accord

Ce que ça ne vous demande pas : apprendre à coder, lire un diff, choisir une architecture — ni construire votre harnais.

La lecture transverse CTO / DSI

Si vous êtes CTO ou DSI et que vous lisez par-dessus l’épaule de votre MOA, quatre choses changent.

Le goulot d’étranglement se déplace. Ce n’est plus la production de code, c’est la disponibilité de l’expert métier. Un projet peut aller vite et s’arrêter net parce que la MOA n’est pas là. La vélocité de l’IA ne compense pas l’absence de décision.

Le rôle du dev change. Il devient facilitateur, traducteur et gardien du dépôt et du harnais. Il doit savoir dire non à l’IA qui propose trop, et à la MOA qui demande hors scope. C’est un métier différent, pas un métier en moins.

Le risque change de nature. L’effet démo guette : une mini-recette réussie donne une impression de fini qui n’est pas de la qualité. D’où la règle : la mini-recette ne remplace jamais l’homologation.

La gouvernance des artefacts devient un enjeu de production. Le glossaire et les ADR ne sont plus de la doc pour devs : ce sont les API du métier vers les IA. S’ils sont périmés, l’IA de la MOA challenge sur une fausse mémoire — et produit une spec confiante et fausse.

Le harnais de la MOA n’est pas un prompt personnel. C’est un actif du projet, intégré au dépôt, fourni et maintenu par le dev comme le reste du code.

Et l’économie est simple : le temps gagné à la fin est payé au début. Si vous ne le payez pas, vous ne l’économisez pas — vous déplacez la dette vers la recette.

Ce que ça ne remplace pas

Des artefacts périmés → les deux IA raisonnent sur une fausse mémoire.
Un harnais non maintenu → l’IA de la MOA challenge avec les règles d’hier.
Une MOA qui signe la spec de son IA sans la relire → le grill devient un dialogue d’IA sans arbitrage.
Deux IA d’accord → ce n’est pas une validation.
Un expert métier indisponible → le grill devient un téléphone arabe.
Un sujet réglementaire → la recette profonde reste le seul juge.
Un bug évident ou un changement de libellé → le rituel complet est surdimensionné.
Un spike → on jette, on ne documente pas.

Le pair programming avec la MOA n’est pas une méthode universelle. C’est un investissement qui se justifie quand le coût d’un malentendu dépasse le coût d’une heure à deux.

Conclusion

Le pair programming avec la MOA ne consiste pas à lui apprendre à coder. Il consiste à lui rendre le moment où son métier devient du logiciel — et à lui donner les moyens de préparer ce moment avec ses propres outils.

La MOA écrit sa spec avec son IA, dans le harnais que le dev lui a fourni. L’IA de codage la grille. Le dev tranche la faisabilité. La MOA tranche le métier. Et le commit reste une signature humaine.

👉 Vous n’êtes pas là pour valider du code. Vous êtes là pour trancher du métier.

Ce n’est pas une perte de temps pour la MOA. C’est du temps qu’elle ne passera pas à découvrir, trois semaines plus tard, qu’on a construit la mauvaise chose.

💬 Et chez vous, à quel moment la MOA voit-elle l’écran pour la première fois : pendant qu’on le construit, ou à la recette ?