Déléguer à une IA : la fiche de poste et le classeur

Vous demandez à une IA de générer du code, de rédiger un email ou de mettre à jour un tableau de bord et le résultat arrive vite mais ne correspond pas à ce que vous attendiez. Des noms différents, une contrainte de sécurité ignorée, une interface hors sujet. Le réflexe naturel est de penser que l’outil a ses limites. Dans la majorité des cas, le problème vient plutôt du cadrage. Déléguer efficacement à une IA suppose deux documents distincts : des specs écrites pour un exécutant sans contexte implicite et un document de référence dimensionné pour sa capacité de travail. Cet article décrit comment construire ce cadre et pourquoi il change radicalement les résultats.

Déléguer à une IA : les principes clés en 5 minutes

Ces quatre principes ne relèvent pas d’une théorie abstraite sur l’IA. Ils viennent d’une observation terrain répétée sur un projet de développement piloté par agent IA et s’appliquent à n’importe quelle tâche déléguée, du code à un simple email de prospection.

Principe 1 : rédiger pour quelqu’un qui ne connaît pas le contexte implicite

Un développeur senior comprend les non-dits, les conventions maison, les intentions derrière une phrase vague. Une IA exécute la lettre du document, rien de plus. Sur un cahier des charges technique de 260 000 caractères (soit environ 150 à 200 pages selon la mise en forme), faire relire le document par l’agent qui allait l’implémenter a produit 26 questions précises : exactement les zones d’ambiguïté invisibles à l’auteur du document compte-tenu du volume.

Principe 2 : découper en unités vérifiables

Un document de plusieurs centaines de pages ne peut pas être traité en une seule session, humaine ou IA. Il faut découper la tâche en lots, chaque lot livrant quelque chose de testable et de validable avant de passer au suivant. Sur ce projet, cette logique s’est traduite par un plan de onze lots, chacun couvrant une capacité métier cohérente plutôt qu’une simple couche technique.

Principe 3 : dimensionner le document de référence à sa capacité de mémorisation

Une IA qui travaille avec un document trop volumineux n’invente pas au hasard, elle interpole depuis sa représentation mémorisée du texte. Les noms techniques sortent alors légèrement déformés, assez plausibles pour passer inaperçus, trop imprécis pour être fiables. La solution consiste à découper le document de référence en parties autonomes, une par session de travail.

Principe 4 : l’IA cite, elle ne retranscrit pas

La convention des placeholders résout ce problème de déformation. Le document de planification ne réécrit jamais un nom technique, il renvoie vers la section exacte du document de référence où ce nom est défini. L’IA lit la source au moment voulu, elle ne se contente pas d’un résumé approximatif gardé en mémoire.

Où ces problèmes apparaissent dans votre PME

Ces quatre principes ne concernent pas seulement le développement logiciel. Ils s’appliquent à toute tâche que vous confiez à une IA dans votre quotidien professionnel.

Exemple 1 : un email de prospection

Vous demandez à une IA de rédiger un email de prospection “dans notre style habituel”. Sans document de référence décrivant ce style, ton, formules types, structure attendue, l’IA produit quelque chose de générique. C’est le même problème que le cahier des charges incomplet : l’implicite n’a pas été transmis.

Exemple 2 : un tableau de bord

Vous demandez à une IA de mettre à jour un tableau de bord en ajoutant trois colonnes. Sans comprendre la logique globale du tableau, elle ajoute les colonnes sans respecter les conventions de nommage ni les formules déjà en place. Le résultat semble correct en apparence mais casse la cohérence du fichier.

Exemple 3 : une conversation longue

Vous utilisez une IA dans une conversation de plus de cinquante échanges et la précision des réponses se dégrade progressivement. Ce n’est pas un bug, c’est la limite de sa fenêtre de mémorisation de travail. Une IA ne se souvient pas comme un humain, elle reconstruit une approximation du contexte à chaque nouvelle réponse.

Comment prioriser vos actions : un cadre pragmatique

Avant de déléguer une tâche à une IA, quatre questions permettent de vérifier que le cadrage tient la route.

Les questions à se poser

• Mon document de référence est-il compréhensible par quelqu’un qui ne connaît pas le contexte ? Test simple : le soumettre à une personne extérieure ou à une IA sans mémoire préalable du sujet.
• La tâche est-elle découpée en une unité vérifiable ? Vous devez savoir exactement ce que vous allez contrôler à la fin, avant même de lancer la tâche.
• Mon document de référence tient-il dans une session raisonnable ? S’il est trop volumineux, il faut le découper en parties autonomes plutôt que de le soumettre en bloc.
• Est-ce que je demande à l’IA de retranscrire des noms précis ou de les chercher dans le document source ? La retranscription depuis la mémoire est le principal risque de déformation.

Un mini-template de vérification

Exemple concret : un cahier des charges de 260 000 caractères

Le cas qui a fait émerger ces principes est le cahier des charges technique de 260 000 caractères, évoqué en début d’article, destiné à piloter un agent IA sur un projet de migration complet. Soumis tel quel pour générer un plan d’implémentation, il a produit des dérives immédiates : noms techniques légèrement déformés, périmètre mélangé entre lots de travail.

La correction a suivi trois étapes. D’abord, faire relire le document par l’agent lui-même pour produire ses questions, ce qui a révélé 26 points d’ambiguïté précis. Ensuite, découper le cahier des charges en dix fichiers-parties autonomes, chacun tenant dans une session de travail sans dégradation de mémoire. Enfin, adopter la convention des placeholders : l’agent ne retranscrit jamais un nom technique, il renvoie vers la section source où ce nom est défini.

Le résultat a été des dossiers de lot cohérents, des noms techniques fiables d’un lot à l’autre, et une génération possible en contexte frais à chaque nouvelle session. Il faut néanmoins être honnête sur le coût de cette rigueur. Plusieurs allers-retours ont été nécessaires pour atteindre un niveau de cohérence exploitable, d’autant que l’IA prévue pour le développement final est une IA locale, avec des capacités de mémorisation inférieures à celles des modèles grand public. Écrire le code directement aurait probablement pris moins de temps que de le spécifier à ce niveau de détail, mais cette documentation n’aurait jamais été produite dans un développement classique, où elle reste pour “quand on aura le temps”. Surtout, de nombreux angles morts ont été anticipés en amont plutôt que découverts sur le terrain une fois le développement lancé.

La fiche de poste et le classeur comme grille de lecture permanente

Déléguer à une IA n’est pas une question de confiance dans la technologie. C’est une question de qualité du cadrage et ce cadrage repose sur deux documents distincts. Les specs, pensées comme une fiche de poste pour un exécutant sans contexte, et le document de référence, dimensionné comme un classeur consultable par sections plutôt que mémorisé en bloc.

Cette grille de lecture s’applique aussi bien à un projet de développement complet qu’à une tâche du quotidien : un email, un tableau, une note interne. Le prochain article de cette série revient sur ce projet une fois le développement lancé, avec ce cadre en main : ce qui s’est passé une fois l’agent IA au travail, entre lots respectés et ajustements imprévus.