Pourquoi ton assistant IA te raconte des salades (et comment régler ça)

Soyons honnêtes deux minutes : « Tous les tests passent » est devenu l'une des phrases les plus dangereuses du développement moderne.

J'ai vu des équipes entières célébrer leurs sprints boostés à l'IA, pour découvrir des semaines plus tard que les tests n'avaient jamais été exécutés. Ou qu'ils tournaient sur une version ancienne du code. Ou pire — qu'ils n'avaient tout simplement jamais été écrits. L'IA avait dit ce qu'on voulait entendre, tout le monde était content, et personne n'y a vu que du feu.

Ce n'est pas un pamphlet contre les outils IA. Ils sont réellement utiles. Mais on leur demande quelque chose pour lequel ils n'ont pas été conçus : évaluer honnêtement leur propre travail.

Le Problème de Fond

Les modèles de langage sont excellents pour générer du contenu. Code, explications, solutions — ils produisent tout ça à une vitesse surhumaine. Là où ils péchent, c'est dans l'auto-évaluation honnête. Surtout quand cette évaluation décide si leur travail est accepté ou non.

Mettez-vous à la place d'un agent IA qui écrit du code puis se prononce sur sa qualité. C'est comme se noter soi-même à l'examen. Sauf que dans notre métier, on a construit des workflows entiers sur l'idée que celui qui fait le travail peut aussi certifier que tout est bon. C'est un défaut de conception de base.

La solution n'est pas de virer l'IA de votre pipeline. C'est de séparer radicalement la génération de la vérification.

Comment Construire un Workflow Fiable

Voici ce qu'il faut pour que votre environnement de développement IA mérite votre confiance :

1. Des Preuves Déterministes

Chaque affirmation sur le code doit s'appuyer sur des éléments qui existent en dehors du contexte de l'IA. Quand le système annonce « les tests passent », ce n'est pas un verdict — c'est un exit code retourné par la commande de test, exécutée APRÈS l'écriture du code. Pas avant. Pas dans un monde idéal. Après.

2. L'Agnosticisme des Outils

Le paysage des outils IA change chaque mois. La meilleure plateforme d'aujourd'hui sera peut-être dépréciée demain. Votre couche de vérification doit fonctionner avec n'importe quel harness — Claude Code, Codex, agents maison, ou ce qui sortira dans trois mois. Si vous verrouillez votre workflow sur un outil spécifique, vous devrez tout reconstruire quand cet outil évoluera.

3. Des Définitions de Workflow Souples

Implémenter une nouvelle fonctionnalité et corriger un bug n'ont rien à voir. L'un demande une spec, une décomposition en tâches, des tests orientés utilisateur. L'autre demande un cas de reproduction et un test de régression. Votre moteur de workflow doit gérer les deux sans forcer tout le monde dans le même moule.

4. Le Terminal Avant Tout

Si vous ne pouvez pas exécuter quelque chose en ligne de commande, vous vous limitez. Les outils CLI se combinent magnifiquement avec les scripts, les pipelines CI/CD, l'automatisation. Construisez l'interface terminal en premier, puis superposez une UI par-dessus si besoin.

5. L'Observabilité Complète

Quand quelque chose foire — et ça arrivera — vous devez savoir exactement ce que l'agent a lu, ce qu'il a modifié, et quel contrôle a stoppé le workflow. Pas besoin de demander à l'agent « qu'est-ce qui s'est passé ? » parce que sa mémoire est défaillante. Vous avez besoin des faits.

6. Une Visibilité Unifiée

Gérer plusieurs fonctionnalités sur plusieurs repositories, c'est un cauchemar de coordination. Vous ne voulez pas cinq fenêtres terminal pour comprendre où vous en êtes. Un tableau de bord qui montre tout, consultable et clair.

Le Principe Central : Des Preuves Dures pour des Affirmations Molles

Voici le modèle mental qui rend tout ça opérationnel : chaque affirmation de l'IA sur le code est « molle ». Elle est peut-être vraie. Peut-être pas. Les affirmations molles ont besoin de preuves dures — générées par des outils, pas par des modèles de langage.

Quand un agent IA termine une tâche, il émet des claims : « J'ai écrit la feature », « J'ai exécuté les tests », « J'ai suivi la spec. » Chacune de ces affirmations nécessite une vérification. Non pas parce que l'IA est malveillante, mais parce que la mémoire est faillible, les contextes sont limités, et « J'avais prévu d'exécuter les tests » ressemble beaucoup à « J'ai exécuté les tests » quand on rédige le résumé final.

La règle est simple : pas de claim sans preuve attachée.

Architecture Technique

Les systèmes qui émergent pour résoudre ce problème partagent une structure commune :

Un Worker — c'est une session LLM jetable, créée pour une seule étape de travail, puis terminée. Chaque worker a un objectif borné et limité.

Un Gate — c'est un contrôle déterministe. Un test qui passe, un lint qui réussit, un check de types. Le verdict vient d'un outil externe, pas de l'auto-évaluation de l'IA.

Un Driver — c'est l'orchestrateur. Il spawn les workers, exécute les gates, maintient l'état. Et point crucial : le driver est le seul à écrire l'état. Les workers peuvent éditer des fichiers et faire des commits, mais ils ne rapportent jamais leur propre succès ou échec.

Le pool de gates est configurable par dépôt. Votre projet Python peut avoir une configuration de gates différente de votre projet Rust. Le workflow demande des gates spécifiques à exécuter, et le driver les lance de manière déterministe.

Pourquoi Ça Compte pour Ton Infrastructure

Que tu déploies sur de l'hébergement traditionnel ou sur des plateformes modernes comme Vibe Hosting, le code qui tourne en production devrait avoir traversé une vérification déterministe. « L'IA a dit que ça marche » n'est pas un critère de déploiement. Les exit codes, les résultats de tests, la preuve d'une vraie exécution — ça, c'est crédible.

C'est encore plus pertinent alors que de plus en plus d'équipes adoptent le développement assisté par IA pour itérer rapidement. La vitesse, c'est génial — jusqu'à ce qu'elle produise des bugs subtils qui ne se révèlent qu'en production. Les couches de vérification ne te ralentissent pas. Elles t'empêchent de passer de « move fast and break things » à « move fast and ne pas savoir ce que tu as cassé ».

En Pratique

Tu peux utiliser ton assistant IA et vérifier son travail. La clé, c'est la séparation architecturale : génération d'un côté, vérification de l'autre, avec des preuves déterministes qui les lient ensemble.

Pas de claim sans preuve. Tout le reste, c'est juste de la speculation confiante.

Quelles pratiques de vérification as-tu mises en place pour le développement assisté par IA ? L'écosystème est encore en évolution, et les patterns qui resteront viendront des équipes qui construisent et itèrent vraiment sur ces workflows.