Quelles sont les erreurs classiques du développement assisté par IA ?

Le produit marche à la démonstration et casse devant le premier vrai utilisateur

Cause. Il n’a été essayé que sur le chemin où tout se passe bien, avec des données propres et une seule personne.

Correction. Spécifier les quatre états de chaque écran, et faire la recette en coupant le réseau et en vidant les données.

Le projet est réécrit pour la troisième fois et n’avance pas

Cause. Le besoin réel n’a jamais été écrit ni mesuré : chaque nouvelle idée paraît aussi légitime que la précédente.

Correction. Revenir au cadrage, écrire le problème en une phrase et la mesure de départ. Refuser tout ce qui ne s’y rattache pas.

Une demande de dix lignes produit une différence de quarante fichiers

Cause. Aucun périmètre n’a été fermé : l’agent améliore ce qu’il traverse, parce que rien ne le lui interdit.

Correction. Nommer les fichiers modifiables dans chaque brief, et envoyer toute autre idée dans une section non appliquée.

La chaîne est verte mais les pannes arrivent quand même

Cause. Les tests vérifient que la fonction appelle la fonction. Ils passent toujours et ne prouvent rien.

Correction. Exiger pour chaque test la sortie de son échec AVANT la correction. Un test qui n’a jamais échoué ne teste rien.

Une panne de base affiche un écran de succès ou une liste vide

Cause. Le code lit le résultat sans distinguer « erreur » de « aucune donnée ».

Correction. Traiter l’erreur explicitement partout où l’on va chercher des données, et afficher un état de panne distinct.

Un utilisateur atteint des données qui ne le regardent pas, en modifiant l’adresse

Cause. Le contrôle n’existe que dans l’interface. Le serveur, lui, accepte la demande.

Correction. Poser le jumeau côté serveur ou base, et le vérifier en appelant le serveur sans passer par l’écran.

Deux lignes identiques apparaissent, et les chiffres du rapport sont doublés

Cause. Aucune contrainte d’unicité en base : le double clic, l’onglet dupliqué ou le rejeu réseau créent deux écritures.

Correction. Poser la contrainte en base et rendre l’écriture idempotente. Le contrôle applicatif ne suffit pas.

Une clé a été poussée, puis retirée dans un commit suivant

Cause. Retirer une valeur ne l’efface pas de l’historique : elle reste lisible par quiconque a cloné.

Correction. Révoquer la clé immédiatement, puis nettoyer l’historique. Dans cet ordre : la révocation seule protège.

Un incident survient et personne ne comprend ce qui se passe

Cause. Aucun journal exploitable, aucun identifiant qui relie une plainte à une trace, aucune alerte.

Correction. Poser la corrélation par requête et une alerte qui atteint un humain nommé, avant la mise en service.

Chaque changement casse quelque chose d’autre et prend trois fois plus de temps qu’avant

Cause. Des raccourcis pris sans échéance, accumulés jusqu’à devenir la structure.

Correction. Tenir un registre de dette daté, et traiter une dette par incrément livré. Sans date, elle ne sera jamais traitée.

Le projet devait durer six semaines et en dure vingt, sans que personne sache pourquoi

Cause. Le hors-périmètre n’a jamais été écrit, donc chaque ajout paraissait compris dans le prix.

Correction. Écrire le hors-périmètre dès la spécification, et traiter tout ajout comme un avenant chiffré.

La troisième correction du même problème le rend pire que la première

Cause. L’agent est engagé dans une mauvaise piste et chaque correction s’ajoute au lieu de remplacer.

Correction. Repartir de zéro, dans une session neuve, avec un brief corrigé. Ne jamais tenter une quatrième fois.