Décrire la fonctionnalité attendue avant de la confier à une IA

La responsable des opérations d’une entreprise d’entretien prépare son rapport mensuel dans Excel. Le logiciel de l’entreprise contient les interventions terminées de ses techniciens, mais elle doit les recopier à la main. L’équipe de développement veut demander à une IA d’ajouter un bouton pour télécharger ces données dans un fichier CSV, un format qui s’ouvre dans un tableur.

« Ajouter un export CSV » nomme la fonctionnalité. La demande ne précise toutefois ni les interventions à inclure, ni les colonnes utiles, ni les utilisateurs autorisés. Si ces décisions restent en suspens, l’IA devra deviner les réponses ou s’arrêter pour les demander. Le fichier peut se télécharger sans erreur tout en exigeant beaucoup de travail de nettoyage de la part de la responsable.

Cet exemple fictif montre comment préparer une demande de développement claire, même si la personne qui demande la fonctionnalité ne sait pas programmer.

Partir de l’utilisation du fichier

Demandez à la responsable de montrer son rapport et un court exemple du fichier attendu. Ici, elle veut les interventions terminées pendant un mois donné, pour sa propre entreprise. Les autres entreprises qui utilisent la même application ont leurs propres dossiers.

Convenez du sens du mot « terminée ». Une intervention peut avoir été clôturée, puis rouverte parce que le problème est réapparu. Faut-il l’inclure dans le rapport? C’est une décision liée au fonctionnement de l’entreprise, puisqu’elle change ce que le rapport présente.

La démarche est la même que pour analyser une demande d’automatisation : comprendre le travail à améliorer avant de choisir comment le réaliser sur le plan technique.

Consigner les règles dans un court document

L’équipe peut préparer une fiche des besoins ou un court cahier des charges de la fonctionnalité. Ce document décrit les conditions que le résultat devra remplir pour être accepté. Il accompagne la modification tout au long du développement et de la mise en production.

Décision	Exemple à convenir avec la responsable
Interventions à inclure	Celles de son entreprise qui ont été terminées pendant le mois choisi
Cas particuliers	Une règle explicite pour les interventions rouvertes et annulées
Colonnes	Identifiant, date de fin et statut; aucune note interne ni coordonnée privée
Utilisateurs autorisés	Les comptes ayant reçu le droit de télécharger le fichier
Moment de référence	Les données telles qu’elles étaient au moment de la demande ou de la création du fichier
Échec	Signaler l’échec de la création sans présenter un fichier partiel comme complet
Limites de la tâche	Aucun changement à la facturation ni aux dossiers des autres entreprises

Le moment de référence doit être précisé si la création du fichier prend du temps. Une intervention peut changer entre le clic et le téléchargement. La règle retenue doit convenir à l’usage du rapport.

Pour évaluer la rapidité, convenez d’un volume de données représentatif et d’un délai acceptable. Un délai fixé sans tenir compte du nombre d’interventions à inclure ne permet pas de juger si le téléchargement répond au besoin.

Préparer des exemples pour vérifier le résultat

Créez des données fictives pour deux entreprises, avec des interventions terminées et d’autres à exclure. Pour un compte de la première entreprise, le fichier attendu ne contient que les interventions admissibles de celle-ci. Un compte sans droit de téléchargement doit se voir refuser l’accès.

Vérifiez la récupération du fichier autant que sa création. Masquer le bouton ne suffit pas si une personne peut encore ouvrir le lien de téléchargement d’un autre client. Les recommandations de l’OWASP sur les autorisations préconisent de vérifier les droits à chaque requête et de tester la logique d’autorisation.

Un exemple en langage courant peut servir de référence : « Avec ce compte et ce mois, le fichier doit contenir les interventions 101 et 104. L’intervention 102 est encore ouverte et la 103 appartient à une autre entreprise. Ces deux dernières doivent être exclues. » L’équipe technique peut ensuite transformer cet exemple en test automatisé.

Si le droit de téléchargement est retiré, précisez ce qui doit arriver aux demandes suivantes et aux fichiers encore en préparation. Un fichier déjà enregistré sur l’ordinateur d’une personne ne disparaît pas lorsque ses droits d’accès changent.

Laisser les choix techniques à l’équipe de développement

Le cahier des charges décrit le résultat attendu. Il peut laisser au développeur ou à l’IA le choix de la méthode, par exemple produire le fichier immédiatement ou le préparer en arrière-plan. La solution doit toujours respecter les délais et les règles d’accès convenus.

L’expérience d’Anthropic sur le développement de longue durée décrit une démarche où les critères d’acceptation sont établis avant le développement. La pratique proposée ici poursuit le même objectif : déterminer comment vérifier le résultat avant de développer la fonctionnalité.

Lorsqu’une règle manque, l’IA doit poser une question à laquelle la personne responsable peut répondre. « Une intervention rouverte doit-elle rester dans le rapport des travaux terminés? » appelle une décision précise. Consignez la réponse approuvée dans le cahier des charges pour que la prochaine personne ou session d’IA retrouve les mêmes règles de l’entreprise.

Avant de commencer le développement, examinez le fichier attendu avec son utilisatrice. Si elle doit encore supprimer la moitié des lignes ou deviner le sens d’une date, la demande doit être précisée. L’article suivant explique comment préparer l’application et les outils nécessaires à l’IA.