Tribunes

Développement : l'IA générative aussi a besoin d'une bonne documentation du code

---

Pour les développeurs, disposer d'une bonne documentation est essentiel. Mais le constat vaut aussi pour les assistants basés sur l'IA générative. Sauf qu'humains et machines n'ont pas besoin du même type de documentation.

PublicitéSi le code est important, la documentation de ce code l'est encore plus. Aucun développeur, et aucun logiciel, n'existe en vase clos ; si d'autres développeurs ne peuvent pas comprendre le code que vous avez écrit, celui-ci perd une grande partie de son impact potentiel.

Mais qu'en est-il des machines ? Ont-elles aussi besoin d'une bonne documentation ? La réponse est oui, et laisse entrevoir un avenir pour la "documentation hiérarchisée" (Tiered documentation), un terme décrit pour la première fois par Vlad Ionescu. Comme il le précise, la documentation hiérarchisée signifie « avoir un ensemble de documents pour les développeurs humains et un autre ensemble de documents spécifiquement destinés à la formation du LLM [grand modèle de langage] ». La première doit être facilement consultable par les utilisateurs ; la seconde doit être détaillée pour que des outils tels qu'Amazon CodeWhisperer ou GitHub Copilot puissent améliorer constamment le code. L'objectif ultime : améliorer la productivité des développeurs. Mais de quoi avons-nous besoin pour y parvenir ?

L'importance d'une documentation de qualité

Si vous demandez à un développeur ce dont il a besoin pour être plus productif, il vous répondra invariablement : une excellente documentation. En fait, SlashData pose cette question depuis des années, et cet item arrive systématiquement en tête de liste, devançant nettement la disponibilité d'outils de développements et d'intégration ou de librairies ou encore l'existence de tutoriels.

Bien entendu, c'est plus facile à dire qu'à faire. Bien que nous connaissions l'importance de la documentation (par exemple, pour la transmission des connaissances, comme l'affirme le développeur Jeremy Mikkola), c'est invariablement la tâche que les développeurs de logiciels ont le moins envie de faire. Comme le fait remarquer Kislay Verma, il est très difficile d'écrire une bonne documentation, et ce n'est pas aussi amusant que d'écrire le code lui-même.

En 2022, le développeur Jakub Kočí observait : « le plus gros problème [dans la rédaction de la documentation], c'est la clarté. » Avant de poursuivre : « nous écrivons d'abord du code pour les humains, pas pour les machines. Le faire fonctionner n'est qu'une moitié de la solution, le rendre bien structuré et maintenable en est une autre... souvent plus difficile. » C'était peut-être vrai il y a deux ans, mais en 2024, il est sans doute tout aussi important que les machines comprennent la documentation autant que les développeurs, compte tenu de l'essor des assistants basés sur les LLM comme Amazon CodeWhisperer ou GitHub Copilot.

PublicitéSauf que les machines ont besoin d'une documentation différente de celle des humains - une documentation plus détaillée, par exemple. Autrement dit, au lieu de se simplifier, l'IA générative rend encore plus difficile la tâche que détestent le plus les développeurs.

Introduction de la documentation hiérarchisée

Comme le suggère Vlad Ionescu, « la documentation à plusieurs niveaux est une chose que quelques personnes expérimentent en tant que solution ou solution de contournement pour les assistants de codage LLM... qui sont idiots parce que la documentation est idiote ». Certains éditeurs de logiciels tentent de résoudre ce problème en travaillant directement avec des partenaires pour intégrer des exemples de code, de la documentation, etc. directement dans le LLM. MongoDB (l'employeur de Matt Asay, NDLR) a fait cela avec AWS. Cette approche fonctionne mais n'est pas extensible. Idéalement, en tant que développeur de logiciels, que vous soyez un particulier ou une entreprise, vous souhaitez créer une documentation que les LLM consulteront d'eux-mêmes.

Vous devez également vous assurer que les LLM comprennent votre logiciel à un niveau profond afin qu'ils puissent renvoyer le meilleur code possible lorsque les développeurs le leur demandent. Malheureusement, comme le déplore Vlad Ionescu, « la plupart des éléments de la documentation destinés aux développeurs (ou même aux utilisateurs) sont généralement pensés pour les débutants, ce qui constitue un obstacle » avec les LLM. Avec une personne, il est tout à fait approprié de donner des exemples de démarrage rapide et de code basique, mais si l'on fournit ce type de données à une machine, celle-ci « aura du mal à produire des suggestions de code sérieuses au niveau de la production ».

Du principe... à la réalité

D'où l'idée d'une documentation hiérarchisée offrant, par défaut, aux robots de recherche des LLM des documents très détaillés et approfondis, et aux humains des contenus plus conviviaux, résume Vlad Ionescu. Tel est le principe. Quid de la réalité du terrain ? À ma connaissance, pour l'instant, personne n'a réussi à faire cela, mais il n'y a aucune raison pour que cela ne soit pas le cas dans le futur. Il sera difficile de fournir des documents qui satisfassent à la fois humains et machines, mais au fur et à mesure que nous mettrons au point les méthodologies pour mieux tirer parti des capacités des LLM, les développeurs engrangeront de plus en plus de bénéfices.

Nous sommes encore loin de disposer de LLM capables de produire du code de manière suffisamment efficace et cohérente pour remplacer les compilateurs, comme l'affirme Mike Loukides d'O'Reilly. Mais nous vivons déjà dans un monde où les LLM peuvent aider les développeurs à écrire du bon code. L'amélioration de la documentation destinée aux développeurs et aux LLM dont ils dépendent de plus en plus sera cruciale pour faire progresser la productivité des développeurs.

En complément :
- Peut-on mesurer la productivité des développeurs (sans effet pervers) ?

Article rédigé par

Matt Asay,
Matt Asay s'occupe des relations avec les développeurs chez MongoDB. Il collabore à divers publications spécialisées anglo-saxonne (Infoworld, TechRepublic, The Register...)

Partager cet article