Un agent de codage peut produire rapidement une proposition. La question reste : une proposition de quoi, pour qui, et selon quelles règles ?
Pour la promotion IMIKNDEV, j’ai préparé une ressource autour du développement par spécifications. Le travail commence avant la génération de code.
Donner un contexte précis
Le contexte du projet aide à comprendre les contraintes : à qui sert la fonctionnalité, où elle intervient et quels comportements existent déjà. Décrire ce contexte évite de faire porter au code une décision métier qui n’a pas encore été prise.
Décrire un comportement observable
Une fonctionnalité se décrit plus clairement par ce que l’utilisateur peut faire et ce qui doit se passer que par une liste de fichiers à créer.
Exemple pédagogique : pour un suivi d’absence, préciser qui peut enregistrer une absence, à quelle séance elle est rattachée et comment une correction doit apparaître. L’exemple illustre la méthode ; il ne constitue pas une documentation des règles de notre application interne.
Préparer la relecture
Les critères d’acceptation donnent une base pour vérifier le résultat. Ils permettent de discuter d’un comportement attendu, d’un cas oublié ou d’une règle mal comprise.
Une bonne spécification ne garantit pas un bon résultat. Elle rend la demande plus claire et la relecture plus concrète.
La ressource de l’atelier est disponible sur GitHub. Elle accompagne l’apprentissage ; les choix et la validation restent à expliquer.