L’armurerie est ouverte

Les mitrailleuses ont déjà été distribuées.

Massimo Chieruzzi, co-fondateur d’AdEspresso et Chief AI Officer chez Unkover, a parfaitement résumé la chose : « L’AI vous donne parfois l’impression d’être un singe avec une mitrailleuse. » Nous sommes d’accord. Et de cette intuition, nous dérivons la nôtre : nous sommes le singe, l’arme est déjà entre nos mains, et le problème n’est ni l’un ni l’autre. C’est l’absence de visée.

Cursor, Copilot, Claude Code, v0 — ce ne sont pas des technologies futures en cours de débat lors d’une architecture review. Elles sont déjà actives dans votre stack, générant du code aux côtés de vos ingénieurs, poussant des commits dans vos repositories. L’agent AI a déjà un accès API à votre codebase. La question « devrions-nous autoriser les outils d’AI ? » a été réglée il y a six mois par l’absence de quiconque demandant la permission.

Votre équipe est déjà armée. La seule question est de savoir si vous avez installé l’aimbot.

Qu’est-ce que la gouvernance du code IA ?

La gouvernance du code AI est l’ensemble des règles structurelles qui guident la façon dont les développeurs et les agents AI écrivent, modifient et livrent du code. Ce n’est pas une bureaucratie basée sur les permissions. Ce n’est pas une file de tickets ou une chaîne de validation obligatoire. C’est une application basée sur des guardrails qui opère à la vitesse du développeur : des limites strictes sur les modules de service, des interfaces de dependency explicites et des contract tests qui échouent en CI avant que le mauvais code n’atteigne la production.

Sans cela, chaque pull request généré par AI est une balle tirée dans le noir. Avec, le singe tire toujours — mais chaque balle atterrit là où elle doit.

Le singe atteint la cible

Voilà l’horreur. La fonctionnalité est livrée. Le ticket est fermé. La démo fonctionne parfaitement.

Le singe a atteint la cible. Mais à quel prix ? Car pour atteindre cette cible unique, il a arrosé de trente balles le service d’authentification, le database schema et trois microservices qu’il a déchiquetés au passage, parce que le singe ne vise pas — il arrose.

Le canal Slack célèbre. La production saigne en silence. La régression d’auth n’apparaît pas dans le diff du pull request. Elle apparaît quarante-huit heures plus tard, quand l’ingénieur d’astreinte est appelé à 2 h du matin parce que les jetons de connexion échouent sur toute la plateforme.

La cible n’a jamais été le problème. Les dégâts collatéraux, si.

Pourquoi la code review échoue comme gouvernance

La code review, c’est de la déviation manuelle de balles

La réponse standard n’est pas la formation. Personne n’a six semaines pour des bootcamps. La vraie réponse est pire : faire en sorte que l’ingénieur senior examine chaque pull request.

La code review devient de la déviation de balles. Le senior lit chaque ligne, attrape chaque balle perdue et la redirige vers la cible. Il ne mentore pas. Il n’architecture pas. Il se tient devant le singe, ajustant manuellement chaque tir pour qu’il atterrisse quelque part d’acceptable.

Cela ne passe pas à l’échelle. Un senior. Douze singes. Quatre cents balles par sprint. Le senior s’épuise. La file de review s’allonge. Finalement, il approuve quelque chose qu’il ne devrait pas, non pas par paresse, mais parce que l’attention humaine est une ressource finie et que le singe a des munitions infinies.

Même quand la formation existe, elle se déroule dans un bac à sable. Le vrai singe apprend en tirant des balles réelles en production. Le temps que les leçons soient retenues, la codebase a subi des dégâts qui prendront des trimestres à réparer.

Vous ne pouvez pas embaucher assez de seniors pour dévier manuellement chaque balle. Le calcul ne fonctionne pas.

Le multiplicateur IA : ni fierté, ni peur

Les développeurs juniors, au moins, ressentent quelque chose. Ils sourient dans Slack quand ils livrent vite. Ils ressentent le recul, tôt ou tard, quand le ricochet les frappe sous la forme d’un postmortem ou d’un rollback.

Les agents AI ne ressentent rien. Ni fierté. Ni peur. Ni blâme. Quand la couche d’auth casse à 3 h du matin, personne n’appelle le modèle. On appelle l’humain qui a fusionné le pull request.

Un LLM va « nettoyer la codebase » à 3 h du matin et refactoriser votre couche d’authentification avec une confiance absolue. Il supprimera des champs dépréciés alors que des consommateurs en aval en dépendent encore. Il introduira des dependencies circulaires qui compilent proprement mais cassent à l’exécution. Il fera tout cela poliment, avec d’excellents noms de variables et des commentaires exhaustifs.

Le singe finit par apprendre qu’arroser vous expose aux ricochets. Il apprend à viser d’abord, puis à tirer. Mais d’ici là, les dégâts sont faits.

Autotomy est l’aimbot

C’est ici que la métaphore bascule de l’avertissement à la solution.

On ne retire pas l’arme. On ne planifie pas un cours de sécurité de six semaines que le business annulera de toute façon. On installe l’aimbot.

Autotomy n’est pas un processus d’approbation bureaucratique. Ce n’est pas une file de tickets ou une code review obligatoire par un senior déjà submergé. C’est une gouvernance basée sur des guardrails qui opère à la vitesse du développeur.

Le singe tire toujours. Le singe tire avec plus de confiance parce que le réticule se verrouille sur des cibles valides. Les service boundaries sont des contraintes strictes, pas des suggestions. Les dependencies doivent passer par des interfaces explicites. Les changements de contract se propagent via des chemins vérifiés. La fonctionnalité est livrée, et rien d’autre ne meurt.

C’est la différence entre une gouvernance basée sur les permissions et une gouvernance basée sur les guardrails. La permission dit : arrête-toi et demande. Les guardrails disent : avance à pleine vitesse, et fais confiance à la structure pour arrêter les mauvais tirs avant qu’ils n’atteignent leur cible.

La récompense : les seniors redeviennent des observateurs

Aujourd’hui, vos ingénieurs seniors sont des gardes du corps. Ils se tiennent devant le singe pour attraper les balles perdues. Chaque pull request est un contrôle des dégâts. Chaque review est un triage aux urgences. Le senior passe sa journée à dire « non, ne touche pas à ce fichier » et « non, ce module est interdit » jusqu’à ce que sa propre productivité tombe à zéro.

Avec l’aimbot installé, le senior redevient un observateur. Il valide la dérive du vent. Il confirme les tirs sur les cibles difficiles. Il traque les cas limites que la gouvernance automatisée ne peut pas voir. Il n’est plus un bouclier humain. Il est un multiplicateur de force.

Une gouvernance qui passe à l’échelle est une gouvernance qui ne dépend pas d’un ingénieur senior lisant chaque ligne de code. Elle dépend de règles structurelles si strictes que même un singe avec une mitrailleuse ne peut pas les violer par accident.

Pour un regard plus approfondi sur la façon dont des limites rigides rendent le code généré par AI fiable en production, lisez comment le codage AI fonctionne avec le framework Autotomy. Si vous voulez comprendre où les guardrails s’intègrent dans la stack, lisez à propos de la stack de sécurité AI.

Que faire concrètement ensuite

Si vous gérez une équipe avec des développeurs juniors ou des agents AI, ne commencez pas par un programme de formation. Commencez par des limites strictes.

Définissez les interfaces de module avant que quiconque n’écrive l’implémentation. Faites passer chaque dependency par un composition root. Ajoutez un contract test par frontière. Appliquez les import restrictions en CI pour qu’un pull request ne puisse littéralement pas être fusionné s’il viole l’architecture.

Ces étapes prennent une journée. Elles changent la capacité de votre équipe à faire confiance à ses propres développeurs dès la quatrième semaine. Pour les équipes qui travaillent avec du code généré par AI, ajouter des contract tests à chaque frontière d’API est le premier levier à actionner.

Le singe est déjà dans le bâtiment. L’arme est déjà chargée. Installez l’aimbot, ou préparez-vous à continuer d’attraper des balles.