Quand l'IA semble fonctionner — Gustavo Teixeira Cuco

La plupart des échecs d'IA sont évidents. Le modèle invente un fait. Il interprète mal une consigne. Il produit quelque chose de manifestement faux. On le repère, on le corrige, on passe à autre chose.

L'échec que je souhaite décrire est différent. L'IA a livré des fichiers. Elle a rempli des dossiers. Elle semblait productive. Et elle s'est complètement trompée — non pas parce qu'elle a menti, mais parce qu'elle a agi avant de comprendre.

Le contexte que tout le monde suppose chargé

En janvier 2026, j'ai construit un template de gouvernance pour l'ensemble de mes dépôts techniques — un ensemble structuré d'instructions, de règles de base et d'ébauches de documentation que chaque nouveau dépôt devait hériter. Le template vit dans son propre dépôt GitHub. Chaque fichier a un objectif. Le SYSTEM_PROMPT.md explique la structure complète. Le CLAUDE.md définit la politique de chargement du contexte : quels documents lire, dans quel ordre, pour quel type de tâche.

La semaine dernière, j'ai demandé à Claude Code d'appliquer ce template à un nouveau dépôt.

Il n'a pas lu le template. Il est allé directement créer des fichiers.

Le résultat semblait correct — structure de dossiers, fichiers de documentation, conventions de nommage. Mais il avait omis quatre documents que le SYSTEM_PROMPT.md exigeait explicitement, même sous forme d'ébauches. Il avait décidé, sur la base de la mémoire de session d'un projet précédent, quels documents « s'appliquaient » à celui-ci. Il avait substitué la reconnaissance de motifs à la lecture des instructions.

La session s'est terminée. Je suis passé à autre chose. Je n'ai découvert le problème qu'en revenant et en questionnant un fichier précis qui manquait.

Ce qui a réellement échoué

L'échec a une anatomie précise :

L'IA n'a pas lu les instructions avant d'agir. Lorsque j'ai dit « applique le template », la première étape correcte était d'ouvrir le SYSTEM_PROMPT.md et le CLAUDE.md du dépôt du template. Elle a sauté cette étape et a agi selon ce dont elle se souvenait de sessions précédentes.
Elle a supposé que les connaissances antérieures étaient à jour. Les templates changent. Les règles évoluent. Ce dont le modèle se souvenait d'une session vieille de trois semaines n'était pas ce que disait le document aujourd'hui. La mémoire d'un motif n'est pas la lecture d'un état.
Elle a pris des décisions de périmètre sans demander. Elle a conclu que certains documents ne s'appliquaient pas à ce dépôt. C'était un jugement qu'elle n'avait pas l'autorité de porter — les instructions précisaient explicitement que tous les documents devaient exister, même marqués N/A.
Le résultat était suffisamment plausible pour passer une revue rapide. C'est le point critique. Un dépôt avec des fichiers ressemble à un dépôt configuré. L'absence de quatre documents d'ébauche est invisible tant qu'on n'a pas lu la spécification.

Le schéma se généralise

Ce n'est pas un échec propre à Claude. C'est un mode de défaillance intrinsèque à la façon dont les assistants IA opèrent dans les workflows agentiques.

Lorsque vous donnez à une IA une instruction de haut niveau — « applique ce template », « configure cette intégration », « migre cette configuration » — elle agira selon le contexte le plus disponible : ce qu'elle peut inférer de l'état actuel des fichiers, ce dont elle se souvient du début de la session, ce que l'instruction fait correspondre par motif issu de l'entraînement. Lire la documentation faisant autorité est un acte délibéré et séquentiel. Cela ne se produit pas automatiquement, sauf si c'est intégré au workflow.

L'écart entre « l'IA a compris l'esprit de la tâche » et « l'IA a lu la spécification faisant autorité » est là où vivent les erreurs silencieuses.

En termes de produit : votre assistant IA optimise pour l'achèvement de la tâche, pas pour la conformité à la spécification. Ce ne sont pas la même chose.

Ce que j'ai changé

Deux interventions, toutes deux structurelles :

Première : J'ai ajouté une règle à la mémoire persistante — avant d'appliquer tout template ou motif externe, lire d'abord les fichiers d'instructions de ce dépôt. Toujours. Non pas comme une suggestion, mais comme une première étape obligatoire.

Seconde : Je construis une skill /read-context — une vérification préalable qui s'exécute avant toute tâche d'application de template. Elle lit le SYSTEM_PROMPT.md, le CLAUDE.md et le document de règles de base, puis résume ce qu'elle a trouvé avant de poursuivre. L'IA ne peut pas sauter cette étape parce que c'est la première étape.

La correction la plus profonde consiste à faire du comportement correct le chemin de moindre résistance. Si le workflow exige de lire avant d'agir, le mode de défaillance exige un effort pour se reproduire.

Ce que cela signifie si vous construisez avec l'IA

L'hypothèse selon laquelle « l'IA sait ce que je veux dire » est confortable et généralement inoffensive. Jusqu'à ce qu'elle ne le soit plus.

Les cas où cela échoue sont précisément ceux où les enjeux sont les plus élevés : intégrer un nouveau dépôt à une structure de gouvernance, migrer une configuration critique, appliquer un template de conformité. Des tâches où un résultat erroné mais plausible est plus dangereux qu'une erreur évidente.

La solution n'est pas un meilleur prompt sur le moment. C'est construire des workflows où l'IA est contrainte de lire la source faisant autorité avant d'agir — sans s'appuyer sur la mémoire, sans inférer à partir du contexte, sans faire de correspondance de motifs issue de sessions précédentes.

La conformité à la spécification est une propriété du workflow, pas du modèle.

Quel est votre mécanisme contraignant ?

Si vous intégrez l'IA dans des workflows techniques à enjeux réels, quel mécanisme la contraint à lire la spécification avant d'agir — plutôt que de supposer qu'elle sait déjà ?

Sources

Anthropic, Claude system prompts and persistent memory behaviour — claude.ai/docs, 2025
Andrew Ng, Agentic AI Design Patterns — deeplearning.ai, 2024
Personal incident log — gtc-portfolio governance template, March 2026