L'IA est un outil, pas un pilote

L'IA. Ce terme est à la bouche d'absolument tout le monde, que cette personne soit chef de projet, chef d'entreprise, développeur, ou même vos grands-parents.

Si vous êtes sur les réseaux sociaux, vous avez sûrement remarqué qu'il y a principalement deux types de personnes. Ceux qui n'y croient pas du tout, et ceux qui font absolument tout avec.

Entre les prophètes de l'apocalypse et les vendeurs de rêve, j'ai l'impression qu'on entend peu ceux qui bossent vraiment avec au quotidien. C'est pour cette raison que j'ai décidé d'écrire cet article, histoire d'avoir un texte plus nuancé que de simples posts Twitter taillés pour l'engagement.

Ce qu'on appelle "IA" aujourd'hui

L'intelligence artificielle n'est pas quelque chose de nouveau. Elle est déjà présente dans les systèmes de recommandation de réseaux sociaux (YouTube, Facebook, Netflix), dans les assistants virtuels (Siri, Alexa, Google Assistant) ou encore dans le machine learning qui alimente des tas d'applications du quotidien.

Le terme est devenu omniprésent lors du boom qui s'est accéléré vers 2020, quand OpenAI a sorti son modèle GPT-3. GPT, pour "generative pre-trained transformer", est ce qu'on appelle un LLM (large language model).

Concrètement, c'est un modèle entraîné sur une quantité massive de texte dont le but est de générer du langage. On pourrait le voir comme un perroquet très sophistiqué : il a "lu" une grande partie d'Internet et a appris à produire du texte qui ressemble à ce qu'un humain écrirait.

De nos jours, quand on parle d'IA, le public pense généralement à la génération de texte (les fameux LLM), la génération d'images, la génération de vidéos, ou encore la vision par ordinateur.

Les entreprises du secteur sont en course vers ce qu'on appelle l'AGI (Artificial General Intelligence), une intelligence artificielle qui égalerait ou dépasserait les capacités humaines dans pratiquement toutes les tâches cognitives. Enfin, en théorie. En pratique, personne n'est vraiment d'accord sur ce que ça veut dire. Microsoft et OpenAI ont par exemple défini l'AGI dans leur contrat comme le moment où OpenAI atteindrait 100 milliards de dollars de profits. Une définition financière, pas technique. On n'y est pas encore, et malgré les investissements colossaux, les progrès commencent à ralentir. Augmenter la puissance et les données d'entraînement ne suffit plus à améliorer les modèles comme avant. Personne ne sait vraiment quand, ni même si, on atteindra un jour cette fameuse AGI.

Sans parler de tout l'aspect éthique des sources de données d'entraînement, on va surtout se concentrer sur les LLM, qui sont les plus en vogue dans notre domaine.

Mais pour comprendre pourquoi ces outils peuvent nous induire en erreur, il faut d'abord comprendre comment ils fonctionnent.

Du texte au texte : comment fonctionne un LLM

Quand on y pense, c'est quoi écrire du code ? C'est la même chose qu'écrire un livre, un article ou n'importe quel autre texte. Il doit être formaté d'une certaine manière, mais ce n'est rien d'autre que du texte. Un LLM est donc tout à fait adapté pour en produire.

Mais savez-vous comment un LLM fonctionne réellement ?

On ne va pas entrer dans les détails, mais ce qu'il faut comprendre, c'est que les machines traitent des nombres, pas du texte. Il faut donc convertir votre prompt en quelque chose qu'elles peuvent manipuler. Ce processus s'appelle la tokenisation : on découpe votre texte en petits morceaux (tokens) qui sont ensuite convertis en vecteurs numériques.

Avant même de recevoir votre prompt, le modèle a été entraîné sur un jeu de données précis. C'est pour cela qu'il existe des biais dans les modèles, et que certains seront plus aptes à écrire du code que d'autres.

Une fois votre prompt reçu, le modèle calcule quels mots ont la plus forte probabilité d'apparaître ensuite, en se basant sur tout ce qu'il a vu durant son entraînement. Puis il recommence avec le mot qu'il vient de générer. Et ainsi de suite jusqu'à ce que la réponse soit complète.

Le résultat ressemble à ce qu'un humain écrirait, mais le processus n'a rien à voir. Même les modèles dits "reasoning" ne raisonnent pas vraiment au sens humain. Ils génèrent des étapes intermédiaires, une sorte de chaîne de pensée, mais chaque étape reste de la prédiction statistique. C'est plus sophistiqué, ça donne de meilleurs résultats sur certains problèmes, mais le fondement reste le même : du texte statistiquement plausible, pas une réflexion.

Les limites d'un système de prédiction

Comme vous pouvez l'imaginer, ce fonctionnement par prédiction cause plusieurs problèmes. Le premier : l'IA n'est pas déterministe. Posez deux fois la même question, vous obtiendrez deux réponses différentes. Ça rend l'automatisation de certaines tâches compliquée. Il existe des moyens de forcer un format précis de résultat, mais ce n'est pas toujours évident.

Le second problème est plus sournois : l'hallucination. Vu que l'IA ne "sait" rien et ne fait que prédire du texte, il est tout à fait possible qu'elle vous sorte des réponses péremptoires qui sont tout simplement fausses. "Utilise l'API User.fetchAllClient() pour répondre à ton besoin", alors que cette API n'a jamais existé.

On a tous déjà eu ce genre d'échange : "EXCELLENT ! Ta théorie est bien meilleure ! 🎯", puis "En fait, je ne suis pas sûr que ce soit nécessaire ! 😅", pour finir trois messages plus loin par : "HA ! Tu as TOTALEMENT raison ! 😂". L'IA acquiesce, se contredit, reformule, et vous donne l'impression d'avoir trouvé la solution. Jusqu'à ce que vous réalisiez qu'elle vous a mené dans un cul-de-sac.

Voici un test généré par Claude Code sur un de mes projets :

test('should extract questionId from direct form data', async ({ assert }) => { 
  const mockDirectRequest = {  
    questionId: 123,  
    selectedAnswer: 1,  
  }  
  
  let { questionId, selectedAnswer } = mockDirectRequest  
  
  assert.equal(questionId, 123)  
  assert.equal(selectedAnswer, 1)  
  assert.isDefined(questionId)  
})

Ce test ne teste absolument rien. Il définit des valeurs, puis vérifie que ces mêmes valeurs existent. C'est l'équivalent d'écrire const x = 5 puis d'affirmer fièrement que x vaut bien 5. Aucune logique métier n'est testée, aucun comportement réel de l'application.

Ces problèmes n'ont pas de solution, en tout cas pas avec le fonctionnement actuel des LLM. Et c'est selon moi ce qui pose le plus de soucis, surtout pour les débutants.

C'est là qu'intervient un biais cognitif appelé l'amnésie de Gell-Mann. Crichton, qui a inventé le terme, le décrit ainsi : vous lisez un article de journal sur un sujet que vous maîtrisez, et vous constatez que le journaliste n'a rien compris. L'article est truffé d'erreurs, parfois au point d'inverser la cause et l'effet. Pourtant, vous tournez la page, et vous lisez l'article suivant sur un sujet que vous ne connaissez pas avec un intérêt renouvelé, comme si celui-ci était forcément plus fiable.

Avec l'IA, c'est pareil. Un développeur expérimenté sait filtrer. Il repère quand l'information est douteuse, quand il y a potentiellement une faille ou une erreur. Un débutant n'a pas ce recul.

Avant, ce débutant allait sur Stack Overflow. Le code qu'il y trouvait n'était pas toujours parfait, mais il avait été validé par une communauté. Il y avait des votes, des commentaires qui corrigeaient les erreurs, des réponses alternatives. Aujourd'hui, ce même débutant pose sa question à l'IA et obtient une réponse unique, confiante, sans garde-fou. Personne pour dire "attention, cette approche pose tel problème".

C'est la grande différence avec un humain, et surtout avec un groupe d'humains. Un humain peut se tromper, mais il a de l'expérience, du vécu, un contexte. Un groupe d'humains peut remettre en question ses propres théories. L'IA ne le fera pas, sauf si vous lui demandez explicitement.

Malgré ces limites, certains ont décidé de tout lui déléguer.

Le mirage du vibe coding

Retournons à nos vendeurs de rêves et prophètes de l'apocalypse. Certains prédisent le remplacement pur et simple des développeurs. On notera que c'était déjà le cas quand le "no-code" est arrivé dans nos vies.

Le "vibe coding" est un terme récent qui décrit un "codeur" qui ne fait rien d'autre que prompter une IA pour qu'elle génère du code à sa place. Il ne relit pas, n'édite pas, et possiblement ne comprend même pas ce qui a été produit.

Ce processus vous place en tant que client : vous évaluez le résultat, mais la démarche et le chemin n'ont pas d'importance. Vous devez aller d'un point A à un point B, que vous preniez l'autoroute ou des petites routes pour économiser de l'essence, peu importe.

Le problème, c'est que ça ne scale pas. Selon la taille du projet, on tombe rapidement dans ce qu'on appelle l'AI loop. Quand le scope devient trop grand, l'IA perd le fil. Elle n'a qu'une fenêtre de contexte limitée : elle ne peut pas garder en tête l'ensemble de votre projet. Une modification toute simple peut alors casser quelque chose à l'autre bout de l'application, et on entre dans une boucle infinie où chaque correction en crée une nouvelle.

Je trouve le concept tout de même intéressant pour itérer rapidement sur une idée, quand seul le résultat compte. Un prototype, une démo, une preuve de concept. Mais ce résultat ne doit à mon avis jamais voir la production en l'état.

Nous ne sommes pas dans une cour de récréation. Mettre en production une application n'est pas un jeu, et sécuriser les données de vos utilisateurs ne l'est pas non plus. Vous êtes responsable de votre code, même si vous ne l'avez pas vraiment écrit.

Alors, comment utiliser l'IA sans tomber dans ces pièges ?

L'IA comme outil, pas comme pilote

Pour moi, l'IA n'est rien d'autre qu'un outil, au même titre que mon IDE. Elle est là pour me rendre plus productif, pas pour me remplacer. Elle me permet de déléguer les tâches lentes et fastidieuses.

Avant de détailler comment je l'utilise, un peu de contexte. Je travaille à la Fédération Internationale de Volleyball. Mon quotidien est varié : répondre à des mails (support, offres, coordination), créer des tickets techniques à partir de discussions avec les différents départements, développer nos applications métier (gestion de congrès, transferts de joueurs, compétitions), et gérer l'infrastructure (serveurs, réseau, firewall).

Contrairement à ce que beaucoup pensent, le métier de développeur ne se résume pas à écrire du code, ou comme j'aime le dire : "pisser du code". Il faut concevoir une architecture, comprendre les besoins métiers, faire des choix techniques en fonction des contraintes, anticiper la maintenance, communiquer avec les équipes non-techniques. Écrire du code, c'est peut-être 30% du travail.

Par exemple, absolument tous les textes que j'écris passent par ChatGPT ou Claude (même cet article). J'écris toujours mon texte à la main, mais je demande ensuite à l'IA d'harmoniser le tout et de corriger mes fautes.

Lors des réunions, je prends mes notes comme d'habitude, mais j'enregistre également l'audio que je passe ensuite à une IA pour obtenir un résumé plus détaillé.

Concernant le code, j'ai plusieurs manières de travailler. Pour la conception, j'utilise ce que j'appelle le "prompting inversé" : c'est moi qui me fais questionner par l'IA, pas l'inverse.

Le processus est simple. Je pose toute ma réflexion par écrit dans un document : le contexte, le problème, la solution que j'imagine. Puis je demande à l'IA : "Lis ce document. Est-ce que tu as des interrogations ? Est-ce qu'il y a quelque chose qui n'est pas clair ou qui pourrait être plus précis ? Est-ce que tu vois une meilleure approche ? Pose-moi des questions."

L'IA va alors soulever des cas d'usage que je n'avais pas imaginés, des ambiguïtés dans ma formulation, des zones d'ombre. S'ensuit une discussion qui étoffe le document petit à petit. À la fin, tout est prêt pour commencer à coder.

J'utilise le même processus pour créer des tickets. Après une réunion, je commence par décrire le contexte de l'issue à l'IA, et elle me pose des questions dessus. C'est redoutablement efficace : quand on écrit, on omet souvent des choses en partant du principe que tout le monde a le même contexte que nous. L'IA, elle, n'a pas ce contexte. Ses questions révèlent les trous dans mon explication, exactement ce qu'un développeur qui lirait le ticket pourrait se demander.

Ce processus est encore meilleur quand il est réalisé avec ses pairs. Plus de cerveaux, c'est toujours plus de cas d'usage inattendus. L'IA n'est rien de plus qu'un pair supplémentaire dans ce cas-là.

Pour l'écriture de code à proprement parler, j'utilise l'IA pour les tâches répétitives : du refactoring simple, du CRUD basique. J'adore faire des commits atomiques, des petits commits bien précis qui permettent de suivre l'évolution du projet et de revert facilement si besoin. Mais il m'arrive de m'emballer et de me retrouver avec des modifications dans tous les sens. Dans ce cas, soit je passe plusieurs minutes à découper manuellement mes changements, soit je demande à l'IA de me créer des commits atomiques à partir de mes modifications.

En revanche, il y a des moments où je n'utilise pas l'IA du tout. Notamment au début d'un projet, quand il n'y a pas encore de cadre établi. Une IA sans contraintes claires va partir dans tous les sens et produire quelque chose d'incohérent. C'est à moi de poser les fondations, de définir l'architecture, les conventions, la structure. Une fois ce cadre en place, l'IA peut m'aider à le remplir.

Par exemple, sur un de mes projets, j'ai un fichier claude.md à la racine qui sert de point d'entrée :

## Vue d'ensemble

**Boring Money** est une application de gestion de budget orientée 
"cash flow" plutôt que "account tracking". L'objectif est de suivre 
les revenus et dépenses mensuels, calculer le taux d'épargne, et 
suivre l'évolution du patrimoine dans le temps.

## Documentation de référence

Avant de travailler sur ce projet, consulte ces documents :

1. **docs/spec.md** : Spécifications complètes du projet
2. **docs/development-guide.md** : Guide de développement
   
...

Ce fichier fait plus de 300 lignes et couvre la vision du projet, la stack technique, l'architecture des dossiers, les conventions de nommage, le workflow de développement, et même une FAQ pour les cas particuliers. Par exemple :

**Q: Dois-je créer une Expense lors d'un achat d'investissement ?**
R: Non. Investir n'est pas "dépenser" mais "transférer du patrimoine 
liquide vers des actifs". Le savings rate n'est pas affecté.

Sans cette précision, l'IA aurait probablement créé une dépense à chaque achat d'action, faussant tous les calculs de budget. Ce fichier renvoie aussi vers une spec détaillée et un guide de développement.

Cette documentation n'est pas juste utile à l'IA. Elle l'est pour moi aussi, et pour toute personne qui rejoindrait le projet. L'IA bénéficie simplement d'un cadre qui devrait de toute façon exister (et qui manque souvent).

Conclusion

L'IA ne va pas remplacer les développeurs. Elle amplifie ce que vous êtes déjà.

Un bon développeur avec l'IA devient un développeur encore plus efficace. Il gagne du temps sur les tâches répétitives, il a un partenaire pour challenger ses idées, il peut se concentrer sur ce qui compte vraiment : la conception, l'architecture, la compréhension du métier.

Un mauvais développeur avec l'IA reste un mauvais développeur, voire pire. Il shippe peut-être plus vite, mais il shippe du code qu'il ne comprend pas, qu'il ne sait pas maintenir, qu'il ne pourra pas débugger quand ça cassera en production.

L'outil n'est que ce qu'on en fait.