Nous sommes à un point d'inflexion dans le développement logiciel. La discussion porte souvent sur la manière dont quel l'IA écrit le meilleur code (Claude contre ChatGPT) ou où où cette IA doit résider (IDE ou CLI). Mais c'est la mauvaise discussion.
Le véritable problème n'est pas celui génération du code. Le véritable problème est la validation de celui-ci.
Si nous adoptons l'IA comme des « Vibe Coders » – où nous indiquons l'intention et l'IA s'occupe de l'exécution – nous créons un flux énorme de nouveaux logiciels. Une nuée d'agents IA peut générer en une minute plus de code qu'un développeur senior ne peut en réviser en une semaine. L'humain est devenu le goulot d'étranglement.
La solution n'est pas plus l'humain. La solution est une Autorité de Conception IA.
Traditionnellement, la « Design Authority » est un petit groupe d'architectes qui se réunit une fois par semaine ou par mois pour approuver ou rejeter une conception. Dans un monde de développement d'IA à haute vélocité ce modèle est désespérément obsolète. Il est trop lent et trop réactif.
Si nous passons au « Disposable Code » – un logiciel que nous ne refactorisons pas indéfiniment, mais que nous jetons et régénérons lorsque les exigences changent – notre rôle change fondamentalement. Nous ne sommes plus des maçons posant pierre par pierre. Nous sommes les architectes de l'usine qui imprime les murs.
Mais qui contrôle si ces murs sont droits ?
Une Autorité de Conception IA n'est pas une personne, mais un pipeline. Un « Gauntlet » (parcours d'obstacles) que chaque ligne de code générée doit traverser pour atteindre la production. Ce processus ne remplace pas la revue de code humaine par rien, mais par quelque chose de mieux.
Cela fonctionne en trois couches :
1. Le Pouvoir Exécutif (La Génération)
Nous ne demandons pas à une seule IA de fournir une solution, nous en demandons trois. Nous faisons travailler Gemini 3, GPT-5 et un modèle open source (comme Llama) en parallèle sur le même problème. Cela évite la vision en tunnel et brise la « paresse » dont souffrent parfois les LLM. Cette approche est également étudiée scientifiquement et démontre que vous pouvez prévenir les hallucinations de l'IA et construire des chaînes très longues sans erreurs
2. Le Filtre Dur (La Loi)
Ici, aucune discussion n'est possible. Le code doit compiler. Les linters ne doivent pas se plaindre. Et surtout : les Tests en boîte noire doivent réussir. Nous ne testons pas si la fonction fonctionne en interne (ce que l'IA pourrait manipuler), nous testons si le système fait ce qu'il est censé faire de l'extérieur. Le test échoue ? Directement à la poubelle.
3. Le Filtre Doux (Le Jury IA)
C'est la véritable innovation. Les solutions restantes sont soumises à une « IA de Vote » spécialisée. Cet agent n'écrit pas de code, mais lit du code. Il est formé sur nos principes d'architecture, nos exigences de sécurité (OWASP, ISO) et nos règles de conformité (EU AI Act).
Il vote : « La Solution A est plus rapide, mais la Solution B est plus sûre et s'aligne mieux avec notre architecture de microservices. »
Le gagnant passe en production.
Ce modèle impose une séparation des pouvoirs qui fait souvent défaut dans de nombreuses équipes.
project-description.md, rules.md en principles.md), les exigences strictes. L'architecte détermine ce que ce que nous construisons et pourquoi.
Cela nous libère de la tyrannie des erreurs de syntaxe et nous permet de nous concentrer sur ce que nous faisons de mieux : la pensée systémique, la recherche de la vérité, la structure et la prise de décision.
La question n'est pas de savoir si l'IA peut écrire notre code. C'est déjà décidé. Le code devient en grande partie jetable.
La question est : osez-vous lâcher le contrôle de la exécution pour reprendre le contrôle de la qualité ?