IA et FOMO au max
S’il y a bien une innovation qui suscite le FOMO (Fear of missing out), c’est l’Intelligence Artificielle.
L’IA en pair programming
Le binômage consiste en une revue de code à deux sur un seul poste de travail avec des rôles bien définis :
- le driver (conducteur) tape au clavier
- l’observer (observateur) relève les éventuelles erreurs et suggère des améliorations
En théorie, les participants peuvent échanger les rôles plusieurs fois au cours d’une séance.
Dans la pratique, l’exercice fait souvent office de formation continue avec des profils séniors qui vont guider des profils juniors tout du long.
Le binômage (en anglais “pair programming”) favorise donc le transfert des connaissances et la montée en compétences des nouvelles recrues.
Si ces séances sont souvent bénéfiques et la pratique plébiscitée dans les sondages en entreprise chaque année, il peut y avoir quelques frictions, voire des ratés.
D’une part, ces métiers nous conditionnent à travailler en solitaire.
D’autre part, toutes les boîtes tech n’ont pas la même culture d’entreprise sur le sujet.
Le temps des dévs coûte assez cher et il faut le faire dans une optique d’amélioration globale de la qualité.
Avec des outils comme Copilot, le développeur peut observer et guider l’IA depuis son IDE, l’environnement de développement où sont réunis tous ses outils habituels.
Ce fonctionnement rappelle celui d’une séance de pair programming mais avec un junior sous stéroïdes.
Il pourrait prendre en charge certaines tâches tout de suite et pas dans 6 mois pour peu qu’on lui fournisse les bonnes informations.
Où sont les problèmes pour toutes ces solutions ?
Les sceptiques décrivent une époque absurde où on chercherait désespérément les problèmes que les modèles d’IA pourraient résoudre.
En ce qui concerne le code, je ne suis pas de cet avis même si j’expérimente les limites des plateformes tous les jours.
Pour le moment, c’est l’automatisation qui m’intéresse.
Le développement logiciel reste complexe mais un grand nombre de problèmes sont déjà identifiés. Certaines tâches sont donc inutilement répétitives.
Sur ce point, si on peut guider une IA à la voix pour initialiser le projet, mettre en place toutes les structures basiques, rédiger certains tests, versionner le code, c’est du temps en moins à taper au clavier, corriger des fautes de frappe, nommer des variables, écrire les commits (sauvegarder le code), ouvrir les PRs (soumettre une modification à une revue de code), etc.
Une simple page web sans formulaire prend déjà un temps fou.
Cependant, certains concluent qu’il faut compter autant d’heures sinon bien plus pour arracher à l’IA un projet potable pour la production plutôt que de le taper tout seul avec ses petits doigts.
En effet, les hallucinations sont assez courantes mais il faut aussi remettre en cause sa propre utilisation.
Peut-être que les prompts ne sont pas assez bons et le contexte mal décrit ou incomplet, un peu comme un jeu vidéo où les meilleurs auraient speed runné le jeu pendant que d’autres resteraient bloqués au premier niveau.
Zéro magie
Les dévs n’ont pas attendu l’IA pour automatiser leurs tâches.
Divers scripts permettent de rédiger des suites de commandes pour tester du code ou générer des éléments.
L’IA peut très bien utiliser ces scripts et en rédiger de nouveaux pour son propre fonctionnement.
C’est très concret et aussi familier qu’un npm run build pour ceux à qui ça parle et pour les autres il s’agit d’une commande très classique pour compiler un projet web.
Si un message d’erreur est détecté dans la sortie, l’outil IA peut prendre le message en entrée automatiquement, ce qui nous évite d’avoir à le remonter manuellement dans l’interface de dialogue.
Pas de magie et très peu de dette cognitive supplémentaire dans ce cas précis, surtout si le premier réflexe avait consisté à se rendre sur Stackoverflow.
Les meilleurs tutoriels sur le sujet insistent sur le tri à faire parmi les tâches avant de mettre l’IA sur le coup, et même dans un contexte très spécifique.
Il y a des bugs connus et des abstractions que l’IA est parfaitement capable de gérer avec le bon accompagnement et d’autres où elle va échouer quasi systématiquement.
L’idée n’est pas de balancer l’outil en mode YOLO (le terme existe vraiment !) sur le projet.
C’est toi le produit?
La peur de manquer (FOMO) a rarement été aussi élevée dans l’Histoire de la Tech mais la dimension produit est très peu abordée, or c’est la plus évidente.
Les plateformes ouvrent le robinet juste assez pour rendre les utilisateurs totalement accrocs avant de conditionner la suite à un abonnement payant, et tu vas payer, crois-moi.
Il est très difficile de revenir en arrière quand on a commencé à intégrer ces outils dans le travail quotidien, un peu comme lire une vidéo en vitesse réduite juste après l’avoir passée en accéléré.
Si autant d’ingénieurs optent pour les formules pros ou la facturation au prorata (exemple : Claude) c’est bien qu’il y a un intérêt concret, au-delà du côté early adopter.
L’aspect conversationnel fait parfois oublier qu’il s’agit d’une offre commerciale.
Les géants de la Tech engagent des sommes astronomiques, ne serait-ce que pour faire fonctionner la bête.
MCP et contextualisation
La dernière avancée dont tout le monde parle c’est le MCP (Model Context Protocol), un nouveau protocole destiné à l’IA et qui veut résoudre un des problèmes majeurs des solutions actuelles : le manque de contexte.
Les modèles génériques s’entraînent pour répondre à des demandes génériques.
Si on pouvait calibrer le modèle sur un contexte restreint (à l’échelle de la boîte par exemple), les résultats seraient nécessairement plus précis, non ?
Si on pouvait articuler les briques classiques d’un projet avec un orchestrateur qui irait interroger le modèle pour sélectionner les meilleurs outils pour une tâche donnée et s’occuperait ensuite de toute la mise en œuvre en respectant scrupuleusement nos consignes, on passerait un cap.
C’est un peu la promesse du MCP.
On dresse une liste précise des instances à “contacter”, on donne les identifiants pour se connecter aux comptes correspondants, on indique les permissions accordées ou pas, les APIs à interroger, etc.
L’architecture nécessaire à ce nouveau protocole ne s’éloigne pas tellement des approches classiques type clients/serveurs que les développeurs connaissent bien.
Une fois en place, le but est d’économiser de nombreux allers-retours inutiles dans l’interface de dialogue (exemple : Claude Desktop) et d’éviter les impasses.
Sans toute cette machinerie, l’agent ne sait pas comment répondre à certaines demandes et se contente d’une approche probabilistique basée sur le texte.
Toujours plus de complexité
Le FOMO vient aussi de la constante augmentation du niveau de complexité des projets et l’IA ne va rien arranger à l’affaire.
La confusion est souvent faite entre simplicité d’utilisation et faible complexité des projets.
Si c’est aussi simple à utiliser, c’est bien souvent parce que l’application encaisse toute la complexité :
simplicity is a feature
Dans la réalité, l’IA n’est pas si simple à intégrer et la qualité des prompts influence directement la pertinence des résultats obtenus, or on ne peut pas se fier aux entrées utilisateurs :
don’t trust user inputs