Notion · Faire agir l’IA
Spécification (spec)
Décrire précisément ce qu’on attend d’un outil avant de le faire construire : les cas, les règles, les exceptions. Avec un agent de code, la qualité de la spec fait la qualité du résultat.
Comment ça marche
Un agent de code construit ce qu’on lui décrit. Si la description est floue, il comble avec ce qui lui semble logique, et ce n’est pas forcément votre logique. La spécification est la description qui ne laisse pas de place aux mauvaises surprises : ce que l’outil doit faire, cas par cas, ce qu’il doit refuser, ce qui fait que c’est réussi, et ce qui est en dehors.
Avec un agent, elle s’écrit en dialogue. On décrit le besoin ; l’agent reformule, pose des questions sur les cas limites, propose une structure ; on tranche. En mode plan, il n’écrit rien d’autre que la spec. Puis la spec devient des tests, les tests guident le code, et le code se relit contre la spec. Le travail de l’humain s’est déplacé : moins de code, plus de clarté sur ce qu’on veut.
Un exemple concret
Objectif. Vérifier chaque note de frais déposée et la classer : acceptée, à compléter, ou refusée avec motif. L’outil ne paie rien et n’envoie rien ; il prépare la décision du service comptable.
Entrées. Un fichier par note : montant, date, catégorie, justificatif (image ou PDF), commentaire libre.
Règles. Repas : 25 euros maximum, au-delà « à compléter » avec demande de motif. Transport : train et taxi sans motif ; avion « à compléter » avec motif. Sans justificatif lisible : « à compléter ». Date de plus de 90 jours : « refusée, délai dépassé ». Montant négatif ou nul : « refusée, montant invalide ».
Cas limites. 25,00 euros exactement : accepté. Justificatif d’un montant différent de celui saisi : « à compléter » avec les deux montants. Deux notes identiques le même jour : la seconde « à compléter, doublon possible ».
Hors périmètre. Le remboursement, la comptabilisation, les notes en devises.
Réussite. Sur les 200 notes du dernier trimestre, l’outil donne le même résultat que la comptable dans 95 % des cas, et aucun « accepté » à tort.
Une page et demie, écrite en une heure avec l’agent, qui a posé la question du doublon. Les tests ont été écrits à partir de chaque phrase.
Ce que ça change pour une équipe
- Le besoin est le livrable principal. Le code se refait ; la spec, c’est ce que l’entreprise sait de son processus.
- Les ambiguïtés sortent avant le code. Le cas limite découvert en écrivant la spec coûte une phrase. Découvert en production, il coûte une journée.
- L’agent travaille mieux. Une spec claire donne un plan clair, des tests clairs, et un code qui fait ce qu’il doit.
- L’outil se maintient. Une évolution commence par la spec. Celui qui reprend l’outil dans un an sait ce qu’il fait.
Les limites et les erreurs fréquentes
- Spécifier la solution au lieu du besoin. « Un tableau avec trois colonnes » décrit un écran, pas une tâche. Décrire ce qu’on veut obtenir, et laisser la forme venir.
- Oublier les cas d’erreur. Le cas normal est facile ; ce sont les vides, les doublons, les formats inattendus qui cassent. La spec les liste.
- La spec jamais mise à jour. L’outil évolue, la spec reste. Six mois plus tard, elle ment. Toute modification passe par elle.
- Croire que l’agent la respecte sans vérification. La spec devient des tests ; les tests vérifient. Sans tests, la spec est un souhait.
Pour aller plus loin
Une spec pour un agent de développement contient l’objectif, les contraintes, les critères d’acceptation et des exemples. Elle se rédige souvent avec l’IA elle-même, en mode plan, puis sert de référence pour les tests.
Où ça se situe chez Opora
Programme 04 · Construire des agentsIngénierie agentique pour les équipes techniques
Écrire une spécification avec l’aide de l’agent, puis la transformer en tests et en code, c’est la méthode centrale du programme Construire des agents.
Questions fréquentes
Faut-il un cahier des charges de trente pages ?
Non. Une bonne spécification tient en une à trois pages : l’objectif, les cas (le normal, les exceptions, les erreurs), les règles de décision, les critères de réussite, et ce qui est hors périmètre. Plus courte, elle laisse l’agent deviner ; plus longue, personne ne la lit, et elle se contredit.
Qui écrit la spec ?
La personne qui connaît le besoin, avec l’aide de l’agent. L’agent pose les questions que le métier n’a pas pensé à se poser : que faire si le fichier est vide, si deux clients ont le même nom, si la date est dans le futur. La spec se rédige en dialogue, puis se relit seule.
Que devient la spec une fois l’outil construit ?
Elle reste la référence. Elle sert à écrire les tests, à relire le code, et à faire évoluer l’outil : une modification commence par une modification de la spec. Un outil dont la spec est à jour se maintient ; un outil sans spec se devine.