Coder avec l'IA : c'est encore mieux avec des specs
Il est assez intéressant et drôle à la fois de constater que les outils d’aide au développement prônent désormais que, pour bien faire les choses, il faut les définir en amont. Ceci vous choque-t-il tout comme moi ?
Personnellement, je suis ravi que l’on revienne aux bases, aux fondamentaux et que l’on recommence à écrire, à spécifier, à rédiger, même pour des choses évidentes. On constate bien que lorsque les équipes grossissent, il est nécessaire de se reposer sur de l’écrit, des schémas, des documents, même si leur formalisme n’est pas très stricte, les choses écrites simplement vont nous aider tout au long du projet et sur l’ensemble de sa durée de vie.
J’avais déjà écrit sur ce sujet en début d’année (cf Ennonçons-nous clairement ?), mais les outils progressent et on ne cesse d’inventer de nouveaux concepts (e.g. BMAD) pour améliorer la qualité de la production de code informatique. A priori, nous en serions arrivés au point que plus rien n’est développé par la main de l’homme, on ne passe que par des agents.
Ce que l’on conçoit bien s’énonce clairement, nous disait Boileau, cela n’est pas apparu avec les outils de code par IA générative, cela est vrai depuis le début de l’informatique en fait. Nombreuses sont les méthodes d’organisation de la pensée, des données, du résultat attendu, des tests, alors que l’on fait travailler son ensemble d’agents cela devient indispensable. Oui, mais ça l’était avant aussi.
Même dans les méthodes plus agiles avec des cycles courts et itératifs, il fallait bien de temps en temps repositionner les choses, écrire, détailler, conserver les décisions d’architecture (cf architecture decision record), de façon à ne pas tout perdre. Il fallait s’appuyer sur un socle solide et un design d’architecture qui tienne debout et soit capable de grossir. Il fallait que l’ensemble puisse accueillir des nouvelles fonctionnalités dans le futur sans avoir à trop retoucher l’architecture générale sans quoi les coûts et les délais allaient être impactés. De façon encore plus criante le fameux cycle en V démarrait par du rédactionnel et rien n’était engagé avant d’avoir fini cette phase importante qu’était la conception.
Le développement piloté par les specs semble donc une nouvelle pratique commune lorsque l’on travaille avec des outils d’IA générative. Certains frameworks sont désormais disponibles et assez riches mais ils nécessitent pour la plupart une rigueur importante (définition de plusieurs fichiers avec des contenus bien spécifiques, par exemple bootstrap.md, agents.md, constitution.md, product.md, tech.md, structure.md). Utiliser des outils de génération de ces contenus peut engendrer la création de beaucoup de fichiers descriptifs intermédiaires qu’il faudra relire et potentiellement corriger, on est donc assez loin d’un document de spécifications qui pourrait contenir l’ensemble. Ici, découper le sujet en petits morceaux va aussi permettre aux agents d’IA de ne pas se perdre et de ne pas trop consommer de ressources (par exemple les tokens) pour exécuter une petite tâche.
Lorsque l’on part dans cette direction pour une nouvelle application, pas de souci à priori, c’est assez simple une nouvelle application, les premières itérations, disons jusqu’à une première livraison officielle à des clients, tout va bien. Mais alors, comment effectuer des évolutions et des correctifs ? Doit-on modifier les spécifications et laisser l’outil IA retravailler tout seul, quitte à ce qu’il modifie tout ? Doit-on redocumenter la spécification et corriger également le code manuellement ? Quel est le risque que des pans entiers de l’application soient modifiés entre deux itérations sur la base de spécifications ayant été amendées ? Comment va se comporter la QA, doit-elle tester l’ensemble de fon en comble ou juste la fonctionnalité modifiée ou ajoutée ?
Cette approche avec des équipes agentiques pose de nombreuses questions ; je ne suis pas sûr à cette heure que nous sachions réellement où aller et comment cela va se comporter sur un cycle long ; disons une application qui serait utilisée plusieurs années consécutives. Sans aucun doute les technologies d’IA génératives vont progresser et dans 3 ans on fera autrement, avec d’autres outils, d’autres méthodes ; donc comment assurer la maintenance de ce qui a été produit ?
Et finalement, est-ce que ce que l’on fait pour l’IA ne fonctionnerait pas aussi avec une équipe de vrais humains ? Très probablement et peut-être même plus efficacement que sans spécifications, les mêmes causes produisant généralement les mêmes effets. Revenir aux basiques c’est bien, dommage qu’il faille toute cette armada d’outil IA génératif et la dépense continue de token pour ce faire.
Pour aller plus loin :