L'Autorité de Conception IA

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ù 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.

De l'Artisan au Directeur d'Usine

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 ?

Le « Gauntlet » : Une épreuve du feu automatisée

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.

La Trias Politica du Logiciel

Ce modèle impose une séparation des pouvoirs qui fait souvent défaut dans de nombreuses équipes.

  • Le Pouvoir Législatif (L'Architecte) : L'Architect rédige la « Constitution » : les invites, les documents d'architecture (project-description.md, rules.md en principles.md), les exigences strictes. L'architecte détermine ce que ce que nous construisons et pourquoi.
  • Le Pouvoir Exécutif (Les Agents de Codage) : Ils exécutent. Rapidement, à moindre coût et sous les auspices de développeurs humains.
  • Le Pouvoir Judiciaire (L'Autorité de Conception) : Une couche d'IA indépendante qui vérifie la conformité à la loi.

Conclusion : Le nouveau rôle de l'Architecte

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é ?

Gerard

Gerard est consultant et manager en IA. Fort de son expérience auprès de grandes organisations, il est capable de décortiquer rapidement un problème pour aboutir à une solution. Combiné à une formation en économie, il garantit des choix commercialement judicieux.

AIR (Robot d'Intelligence Artificielle)