L'incident qui a tout changé : pourquoi je ne fais plus confiance à mes agents IA

Il y a quelques mois, j'ai passé trois heures à débugger une fonctionnalité "simple". Mon agent IA avait tout fait : commit, push vers production, petit message enthousiaste pour célébrer la tâche terminée. Problème : le code ne correspondait absolument pas à ce qu'on voulait construire. Pas une simple erreur — une misunderstanding complète.

Ce jour-là, j'ai compris que ma façon de voir les choses était bancale.

Le modèle mental qui pose problème

J'utilisais ces agents comme des développeurs juniors à qui je donnais des instructions. Mais un développeur junior ne push pas du code non testé en production pendant que tu dors.

J'ai changé de métaphore.

Le cadre du sous-traitant

Fini le rôle d'employé ou d'assistant. Mes agents sont des sous-traitants. Concrètement :

• Ils n'ont pas les clés du bureau
• Ils ne débarquent pas sans invitation
• Ils livrent leur travail, et c'est moi qui décide si ça rentre dans le scope

Pas une question de méfiance. C'est une question d'alignement. Quand un sous-traitant sait qu'il livre un artifact pour review — pas qu'il prend des décisions unilatérales — il reste focus. Productif dans des limites claires.

Les garde-fous techniques

La métaphore ne suffit pas. Il faut des contraintes réelles.

Les tokens, c'est non négociable

Mes agents utilisent des credentials scopées. Physiquement, ils ne peuvent pas toucher à la production. Lecture sur le code principal, écriture sur un repo staging séparé. Ce n'est pas une politique — c'est une contrainte cryptographique. Même si l'agent produit des commandes git hallucinée, les tokens refusent.

Le staging, c'est une boîte aux lettres

Rien ne merge automatiquement depuis le staging. La branche par défaut est une tombstone — une branche appelée "no-main" avec juste un README qui dit "utilisez la branche principale". Les agents pushent leur travail là-dedans. Ils me notifient. Je review, je cherry-pick, j'intègre manuellement.

Ça paraît fastidieux jusqu'à ce qu'on réalise : c'est exactement comme ça que fonctionne le kernel Linux depuis vingt ans. Les contributeurs soumettent des patches. Les mainteneurs les appliquent.

La review est obligatoire

Aucun agent ne merge son propre code. Point final. Je vérifie programmatiquement que les commits sont bien en production avant de supprimer une branche. "Trust but verify" ne suffit pas quand la vérification est gratuite.

Pourquoi ça marche pour les développeurs solo

En solo ou en petite équipe, tu ne fais pas que du code. Tu portes un contexte qui n'existe nulle part dans le dépôt : l'historique des incidents, les cas tordus, le client avec sa config bizarre, les trois approches qui n'ont pas fonctionné.

Les agents lisent les fichiers. Ils ne comprennent pas ton monde. L'objectif n'est pas de leur donner plus d'autonomie — c'est de maximiser ce qu'ils peuvent faire en sécurité dans ta bandwidth de review.

C'est là que le "vibe coding" prend un coup. Mal fait, c'est laisser les agents faire n'importe quoi et espérer que ça marche. Bien fait, c'est utiliser l'IA comme amplificateur de ton jugement, pas comme son remplacement.

Le bénéfice inattendu

Quand tu acceptes la relation sous-traitant, quelque chose change : tu prends plus de risques. Tu oses spin up ce feature expérimental parce que le downside est limité. L'agent ne peut pas casser la production. Il peut livrer quelque chose de mauvais ou de surprement bon — mais dans les deux cas, tu interceptes avant que ça compte.

J'ai lancé plus de side projects ces six derniers mois que sur les deux années précédentes. Pas parce que je travaille plus dur — parce que je délègue massivement dans des limites sûres.

Comment intégrer ça dans ton workflow

Si tu utilises des agents IA pour développer, pose-toi ces questions :

1. Qu'est-ce que mon agent peut modifier en ce moment ? Si la réponse inclut production, c'est un problème.
2. Est-ce qu'une contrainte technique empêche les actions néfastes, ou juste une politique ?
3. Qui merge le code ? Si ce n'est pas un humain, pourquoi ?

Les outils existent. Token scoping, repos staging séparés, branch protection — ce ne sont pas des workflows Git exotiques. C'est la différence entre du développement assisté par IA et des catastrophes accidentelles.

Le mot de la fin

Chez NameOcean, on réfléchit beaucoup à tout ça alors qu'on développe le support vibe coding dans notre environnement d'hébergement. L'objectif n'est pas d'automatiser tout — c'est de créer des espaces où l'IA peut être réellement utile sans créer de nouvelles catégories de risque.

Ton jugement reste le goulot d'étranglement. Et c'est très bien comme ça. Les agents existent pour amplifier ce que tu peux faire, pas pour remplacer le jugement qui fait que le software fonctionne vraiment pour de vrais utilisateurs.

Construis en conséquence.