Sur The Playground, une plateforme communautaire construite par The Spark, une règle d’architecture interdisait une pratique que plusieurs dizaines de fichiers utilisaient pourtant. La consigne était formulée avec assurance. Après vérification, elle était fausse : la pratique interdite correspondait au fonctionnement normal du framework.
Cet épisode pose une question qui dépasse la qualité d’un prompt. Quand on confie l’écriture du code à un agent, comment savoir si les règles qu’on lui donne sont justes ? Et comment vérifier qu’il les respecte ?
La maîtrise du produit se joue aussi à cet endroit. Elle demande de comprendre les choix, de pouvoir les discuter et de disposer de moyens pour examiner leurs conséquences.
Comprendre les décisions qui engagent le produit
On peut commencer par les questions auxquelles l’équipe doit pouvoir répondre. Où sont les données ? Qui peut les consulter ou les modifier ? Quelle partie du produit porte une règle métier ? Que se passe-t-il si un service externe ne répond plus ? Comment revenir sur une modification ?
Ces questions relient architecture et usage. Leur réponse ne tient pas toujours dans un écran ni dans une explication générale de l’agent. Elle peut demander d’examiner une configuration, d’exécuter un test ou de regarder une partie précise du code.
Dans la pratique de construction de The Playground, l’écriture et la relecture systématique du code ont été déléguées aux agents. Les intentions, les arbitrages et la validation des parcours restent portés humainement. C’est une expérience située, conduite avec une longue expérience technique et produit. Elle ne rend pas l’expertise de lecture du code inutile, notamment lorsqu’il faut investiguer un défaut ou examiner un sujet sensible.
L’enjeu est de choisir ce qu’on doit comprendre et le niveau de preuve nécessaire, plutôt que d’assimiler la quantité de code relue à la maîtrise obtenue.
Une explication convaincante reste à vérifier
Un agent peut décrire pourquoi une solution devrait fonctionner. Cette explication est utile pour discuter une proposition. Elle ne démontre pas à elle seule le comportement du système.
La règle erronée de The Playground en est un exemple. On pouvait demander à l’agent de faire respecter le document, puis multiplier les corrections dans le code. Il fallait d’abord revenir au fonctionnement du framework et examiner la contradiction.
Cela implique de conserver les raisons des décisions. Une règle accompagnée de son objectif est plus facile à réévaluer. Si elle vise à empêcher un accès direct aux données depuis certaines parties du produit, on peut examiner ce risque précis. Une interdiction absolue, sans explication, laisse moins de prise à la discussion.
Les documentations officielles, le comportement observé et les contraintes du produit servent à confronter la proposition. Un deuxième agent peut aider à chercher une erreur, mais son accord ne constitue pas une preuve indépendante par nature.
Transformer certaines règles en contrôles
Une fois la règle établie, on peut chercher à la vérifier automatiquement. Un linter, par exemple, analyse le code pour signaler certaines constructions interdites ou incohérentes. Il peut rendre visible un écart à chaque modification, au lieu de compter sur le rappel d’une consigne.
Ce contrôle doit être accessible à l’agent pendant son travail. Son message doit expliquer ce qui pose problème et, si possible, renvoyer à la raison de la règle. L’agent peut alors corriger la proposition avant de la soumettre.
Un contrôle automatique reste limité à ce qu’il examine. Il peut manquer un cas ou bloquer une exception légitime. Il faut donc aussi vérifier le contrôle lui-même, préciser son périmètre et prévoir qui décide d’une exception. Un agent autorisé à modifier librement la règle et son test pourrait faire disparaître l’alerte sans résoudre le problème.
Les règles de sécurité demandent en particulier une application technique des permissions. Les recommandations de l’OWASP sur la sécurité des agents rappellent l’importance de limiter les droits et de contrôler les actions. Une instruction seule ne constitue pas une frontière d’accès.
Garder du jugement là où il est nécessaire
Tout ne se transforme pas en verdict automatique. Une architecture peut respecter les conventions et être inutilement compliquée. Un parcours peut passer les tests tout en imposant trop d’effort à l’utilisateur. Une fonctionnalité peut être correctement construite et ne pas mériter sa place dans le produit.
Ces choix demandent de rapprocher les preuves disponibles de l’objectif poursuivi. Pourquoi ajouter cette abstraction ? Quel changement rendra-t-elle plus simple ? Que coûte-t-elle maintenant ? Une réponse peut conduire à conserver la proposition, à la simplifier ou à demander un avis spécialisé.
C’est aussi ce que les équipes doivent apprendre à transmettre. Les décisions et leurs raisons permettent à une autre personne de reprendre le produit sans dépendre exclusivement de la conversation qui l’a fait naître.
Construire avec l’IA déplace une partie de l’effort vers cette organisation de la compréhension et de la vérification. Notre offre Construire des produits associe ces exigences à la conception et à la livraison. Elles peuvent aussi devenir un sujet de formation pour les équipes techniques.