Ce que j’ai appris en laissant une IA coder seule

Le pipeline de prospection était construit sur des bases solides. Plan de migration en main et maquette fonctionnelle validée, la décision semblait logique : déléguer l’intégralité du développement à l’IA et laisser tourner. Le code arrivait vite. Les tests passaient. Puis les premières vérifications ont révélé quelque chose que les tests ne détectaient pas. Cet article raconte ce qui s’est passé et ce que cette expérience révèle sur les conditions réelles d’une délégation réussie à une IA, bien au-delà du code.

Le point de départ

Au démarrage d’activité, le temps disponible pour la prospection est rare. Après plusieurs semaines à construire un pipeline automatisé (collecte de données, enrichissement, qualification), la maquette fonctionnait de bout en bout. Un plan de migration détaillé avait été rédigé pour passer de cette maquette à une application plus robuste : découpage en modules, architecture pensée pour durer, zéro valeur codée en dur.

Sur le papier, le plan était solide. La décision a donc été prise de passer en mode développement autonome : laisser l’IA travailler avec un périmètre par session, contrôler les tests, avancer vite.

Les premières sessions sont impressionnantes. Le code arrive en volume, les tests automatisés passent, le rythme est sans commune mesure avec ce qu’un développement dirigé permettrait. Puis deux questions surgissent, presque simultanément :

• Comment vais-je analyser ce volume de code produit aussi vite ?
• Comment s’assurer que ce code respecte les specs et les contraintes de sécurité définies ?

Ce sont ces deux questions qui ont conduit aux premières vérifications, elles ont confirmé ce que d’autres retours d’expérience laissaient présager.

Ce qu’on a trouvé en vérifiant

La dégradation n’était pas spectaculaire. Le code tournait, les tests passaient et c’est précisément ce qui rendait les problèmes difficiles à détecter.

Fichiers trop volumineux, logique agglomérée. Plutôt que de produire des modules séparés et indépendants, ce que le plan prévoyait explicitement, l’IA avait tendance à tout concentrer dans des fichiers larges. La logique fonctionnait mais elle était impossible à modifier sans risquer de casser autre chose. La dette technique s’accumulait à la vitesse de la génération.

Incohérences de nommage entre fichiers. Les noms de fonctions et de variables variaient légèrement d’un script à l’autre. Pas assez pour que les tests unitaires le détectent, juste assez pour provoquer des bugs à l’exécution réelle, au moment de l’intégration entre modules. Ce type d’erreur est particulièrement coûteux : silencieux jusqu’à ce qu’il explose, difficile à tracer une fois le volume de code important.

Fonctionnalités produites à côté des specs. L’interface de gestion prévue dans le plan avait été interprétée librement. Le résultat fonctionnait dans l’absolu, mais ne correspondait pas à ce qui avait été décrit. Certaines parties étaient à refaire entièrement.

Contraintes de conception ignorées. Le plan stipulait explicitement : zéro valeur métier codée en dur, tout doit être lu depuis la configuration au démarrage. Cette règle n’avait pas été respectée. Pas par malveillance mais par interprétation. L’IA avait comblé les zones d’ambiguïté du document avec ses propres conventions.

Avec du recul

L’itération a été abandonnée. Pas pour repartir de zéro sur le fond, mais pour reprendre la méthode.

Le diagnostic était simple : le plan de migration était solide pour un développeur senior. Il contenait les décisions d’architecture, les règles de gestion, les contraintes techniques. Un développeur expérimenté comprend le contexte implicite, pose des questions quand une zone est floue, adapte son interprétation au reste du projet. Une IA exécute à la lettre du document qu’on lui fournit. Là où le document était précis, le code était conforme. Là où il laissait de la latitude, les dérives ont commencé.

Ce n’est pas une limite de l’outil mais une propriété fondamentale de la délégation.

La différence entre la première et la troisième colonne ne tient pas à la puissance de l’outil. Elle tient à la qualité du document qu’on lui donne.

Un développeur senior comprend ce qu’on n’a pas dit. Une IA exécute ce qu’on a écrit, pour le meilleur et pour le pire.

Ce que ça change pour une PME

Cette itération a été une perte de temps au sens littéral. Plusieurs jours de génération, de vérification, de tentatives de correction partielles, avant de prendre la décision d’arrêter. Le coût réel n’était pas dans le temps passé à générer du code, c’était le temps passé à comprendre pourquoi ça ne fonctionnait pas comme prévu et à mesurer l’écart entre ce qui avait été produit et ce qui était attendu.

Ce type de situation arrive aussi bien au-delà du code. Demander à une IA de rédiger un email dans notre style habituel sans document décrivant ce style produit quelque chose de générique. Lui demander de mettre à jour un tableau de bord sans comprendre la logique globale aboutit à des incohérences que personne ne détecte avant qu’elles posent un problème.

La question à se poser avant toute délégation à une IA n’est pas “est-ce que cet outil est capable de faire ça ?” mais “est-ce que mon document de référence est suffisamment précis pour que le résultat soit conforme ?”

Les outils d’IA actuels sont d’excellents exécutants. Leur limite n’est pas la compétence, c’est le cadrage. La qualité du résultat est directement proportionnelle à la qualité de la demande. Ce principe vaut pour du code comme pour n’importe quelle tâche déléguée, à un outil comme à un collaborateur.

Déléguer à une IA, ce n’est pas différent de déléguer à quelqu’un qui arrive sans contexte et sans expérience du projet. La qualité de la délégation dépend de la qualité du cadrage, pas de la compétence de l’exécutant.

L’article suivant de cette série décrit comment reconstruire ce cadre : pourquoi la taille du document de référence est aussi importante que son contenu et ce que cette contrainte révèle sur la façon dont les outils d’IA traitent l’information.