Quelques étapes de matu­rité

Je demande parfois « Tu fais quoi avec l’IA ? ». L’in­gé­nie­rie logi­cielle c’est bien plus que taper du code mais je vais ici me concen­trer sur la géné­ra­tion de code.

Le niveau 0 c’est celui qui ne cherche pas à utili­ser l’IA mais qui ne fait pas la chasse non plus. Surprise, à ce niveau on l’uti­lise proba­ble­ment à plusieurs endroits sans le savoir, mais ça reste anec­do­tique.

C’est celui qui ne veut pas en entendre parler et qui fait atten­tion à exclure tout ce qui est lié à l’IA, c’est plutôt le niveau –1¹.

---

Note: Ne sautez pas les étapes. On a besoin de maitri­ser une étape avant de pouvoir passer à la suivante avec succès. Si vous allez trop vite, vous risquez de simple­ment faire n’im­porte quoi.

Pensez aussi à toute votre chaîne. Si votre version­ne­ment, votre inté­gra­tion conti­nue, vos pratiques de revue, votre archi­tec­ture ou vos tests ne sont pas au niveau, ou si globa­le­ment les bonnes pratiques de déve­lop­pe­ment logi­ciel modernes ne sont là, vous risquez de démul­ti­plier le bordel : Garbage in, garbage out.

1. L’usage de surface

L’usage de surface c’est si vous avez confi­guré copi­lot ou un système simi­laire dans votre IDE. Il y a de la complé­tion auto­ma­tique un peu intel­li­gente sur une ou plusieurs lignes.

Honnê­te­ment, si vous n’avez pas une aver­sion forte à l’IA, foncez.

C’est l’étape qui va juste vous appor­ter un peu de confort gratuit sans rien chan­ger à votre métier. Les modèles liés sont des tout petits modèles pour que ça tourne rapi­de­ment, donc il n’y a pas vrai­ment d’enjeu éner­gé­tique non plus.

La première marche est de commen­cer à utili­ser l’in­ter­face de chat pour poser des ques­tions sur un méca­nisme que vous ne connais­sez pas, ou pour comprendre le fonc­tion­ne­ment d’un code qui n’est pas le vôtre.

La seconde marche est l’uti­li­sa­tion des inter­faces de chat pour faire de la géné­ra­tion. Au départ on se contente des sque­lettes géné­riques initiaux qu’on modi­fiera ensuite. Assez vite on tente des modi­fi­ca­tions contex­tuelles locales ou de la revue de code, pour voir.

Ne vous atten­dez à rien d’ex­cep­tion­nel. C’est juste un outil de plus qui peut aider. Pensez à bien gérer votre version­ne­ment, avec des commit avant et après le passage de l’IA, pour annu­ler tout faci­le­ment.

Si vous en êtes là, tentez les fonc­tions de debug de Cursor. Vous allez voir la machine faire des hypo­thèses, monter du moni­to­ring, et itérer jusqu’à trou­ver et corri­ger la source du problème (avec votre aide). Ça ne fonc­tionne pas à tous les coups mais c’est une bonne aide en première inten­tion.

2. Approche tech­nique

Le premier palier inté­res­sant c’est celui là. L’in­ter­face de chat sert à géné­rer le cœur du code. L’idée c’est de commen­cer à plus géné­rer de code qu’en écrire.

Les premières fois on reste sur une approche tech­nique. C’est vous qui deman­dez expli­ci­te­ment quelle fonc­tion, quel fichier, quelle archi­tec­ture.

Cette étape peut être frus­trante, parce qu’on a l’im­pres­sion de prendre un bébé par la main et perdre du temps à tout expliquer ce qu’on pour­rait taper aussi rapi­de­ment, et parfois mieux ou plus court. C’est là qu’on perd pas mal de monde qui « a essayé » sans oser vrai­ment plon­ger dedans.

Commen­cez à vous forcer à faire corri­ger au lieu de corri­ger vous-mêmes, pour apprendre comment faire le prompt. Ajou­tez quelques règles par défaut pour que ça utilise vos styles et vos outils.

Le gain c’est quand, au lieu de faire corri­ger au fur et à mesure, on utilise le mode plan. Là on commence à guider l’ar­chi­tec­ture et à orga­ni­ser ce qu’on veut. C’est aussi un gain direct pour les plus jeunes parce que ça permet de se concen­trer sur l’im­por­tant au lieu de se perdre dans l’im­plé­men­ta­tion.

3. Approche fonc­tion­nelle

Pour moi le vrai palier de valeur ajou­tée a été d’ar­rê­ter de faire du baby-sitting et de commen­cer à donner des inten­tions plutôt que des instruc­tions. Le mode plan se charge de traduire ça et me permet d’in­ter­ve­nir avant la géné­ra­tion elle-même.

Spéci­fiez au fur et à mesure vos choix archi­tec­tu­raux, styles, contraintes et choix tech­no­lo­giques pour que ça vous demande le moins de re-travail possible. Au fur et à mesure, créez des règles cursor/claude pour ça et amélio­rez les chaque fois que vous avez besoin de préci­ser quelque chose de géné­rique.

Vous en êtes là ? Le palier suivant c’est d’im­po­ser des choses comme le TDD et le déve­lop­pe­ment par contrat. Deman­dez de commen­cer par les tests et les inter­faces, faites une revue sérieuse de cette étape. Le risque de surprise dimi­nue énor­mé­ment sur la suite. Ça vous permet­tra aussi de vous concen­trer sur l’im­por­tant.

4. Approche par spéci­fi­ca­tion

Le mode plan est une évidence. Pourquoi ne pas pous­ser plus loin et conce­voir les plans en mode plan ?

On commence par travailler sur des fichiers de spéci­fi­ca­tions fonc­tion­nelles et tech­nique, en mode plan. À partir de ces spéci­fi­ca­tions fonc­tion­nelles et tech­niques, on demande de créer décou­pages des tâches et des plans d’im­plé­men­ta­tion détaillés pour chaque tâche.

On itère sur chaque étape, en se concen­trant d’abord sur le haut niveau, puis en descen­dant avec plus de détail à chaque fois, concen­tré sur une tâche précise. On pourra ensuite deman­der l’exé­cu­tion des tâches, une à une (en mode plan si ça vous amuse, mais c’est proba­ble­ment moins néces­saire à ce niveau là), poten­tiel­le­ment avec un modèle moins coûteux.

C’est un vrai chan­ge­ment de travail mais on ne se détache ni de la tech­nique ni du fonc­tion­nel : on travaille sur l’im­por­tant. Taper des formu­laires, des tests et des fonc­tions utili­taires n’est clai­re­ment pas ce qui me semble le plus stimu­lant. Réflé­chir à quoi faire et comment : si.

Vous en êtes là ? Le palier suivant c’est toujours de penser plan plutôt que de four­nir des instruc­tions et de correc­tions éphé­mères pour modi­fier le résul­tat. Si un code ne corres­pond pas, amélio­rez le fichier de tâche corres­pon­dant et regé­né­rez. Si une tâche ou un enchaî­ne­ment de tâches n’est pas bon, amélio­rez les spéci­fi­ca­tions et regé­né­rez.

L’avan­tage annexe c’est qu’on peut poser quand on veut, travailler à plusieurs, et modi­fier tout ce qu’on souhaite après coup. On a aussi une docu­men­ta­tion durable de ce qu’on fait.

5. Auto­ma­ti­sa­tion

Ce que je vois venir ensuite c’est l’au­to­ma­ti­sa­tion de tout ça. On complète les règles et on crée des agents. On lie nos spéci­fi­ca­tions et nos tâches à la docu­men­ta­tion, leur statut à l’ou­til de gestion de projet.

Les tâches peuvent récu­pé­rer les retours de la chaîne d’in­té­gra­tion conti­nue et plani­fier des correc­tions immé­dia­te­ment avant que vous ne passiez pour la revue manuelle. Même chose pour des pré-revues de code auto­ma­tiques.

Ces revues de code auto­ma­tiques peuvent tenter de quali­fier les risques et propo­ser de vali­der auto­ma­tique­ment les chan­ge­ments non risqués (après une période où on aura confirmé que l’hu­main n’a en effet jamais eu à redire sur les chan­ge­ments quali­fiés comme non-risqués).

On ajoute des agents qui vont surveiller la qualité de code, la main­te­na­bi­lité, la sécu­rité, la cohé­rence, et qui vont tenter des refac­to­ring auto­ma­tique­ment quand il commence à y avoir trop de dupli­ca­tion ou de complexité. On peut aussi ajou­ter des agents qui vont s’oc­cu­per des montées en version qui ont un impact sur le code. Il y a tant de tâches qui peuvent être auto­ma­ti­sées une fois qu’on a un peu de temps libé­ré…

Bref, si le harnais de test est suffi­sant, ce qui ne tient qu’à nous au niveau des spéci­fi­ca­tions et plans d’im­plé­men­ta­tion vu que désor­mais mettre à jour les tests ne coûte pas forcé­ment cher, on peut commen­cer à penser l’in­dus­tria­li­sa­tion de toute la chaîne.

---

1. Pas de juge­ment de valeur. On parle de –1 en terme d’uti­li­sa­tion de l’IA. ↩︎