- À l’ère de l’IA, la pratique la plus contre-intuitive consiste à savoir quand ralentir, et plus l’exécution devient peu coûteuse, plus la prise de décision en amont devient importante
- Le cadre de System 1 (mise en correspondance rapide de motifs) et System 2 (pensée analytique lente) de Daniel Kahneman est appliqué au développement logiciel à l’ère de l’IA
- Des exigences erronées ou des hypothèses de conception incorrectes sont propagées encore plus vite par l’IA, ce qui maximise le rapport coût/efficacité des étapes lentes avant l’exécution
- L’IA peut être utilisée non seulement pour l’exécution, mais aussi pour accélérer les phases de réflexion comme la revue en amont, le pré-mortem et l’exploration des cas limites
- Pour répondre à la nouvelle culture de pression sur la vitesse du type « Il suffit d’utiliser l’IA, non ? », il faut une stratégie qui rende explicites les étapes lentes et les cadre dans un temps défini
Deux vitesses de pensée
- Les deux modes de pensée présentés par Daniel Kahneman dans Thinking, Fast and Slow sont appliqués au développement à l’ère de l’IA
- System 1 : une pensée rapide, automatique et fondée sur la reconnaissance de motifs
- System 2 : une pensée lente, délibérée et analytique
- Lors d’un échange avec Dwarkesh Patel, Andrej Karpathy a comparé les LLM à des fantômes ou des esprits : des distillats statistiques du texte humain, dont la nature est fondamentalement de type System 1, où des mots entrent, des motifs sont reconnus, puis d’autres mots ressortent
- L’IA excelle dans la mise en correspondance rapide de motifs à grande échelle, mais décider quoi construire, pourquoi c’est important et si l’on résout le bon problème reste du domaine du jugement humain
- Point contre-intuitif essentiel : l’IA n’a pas rendu les étapes lentes moins importantes, elle les a rendues plus importantes encore
- Quand l’exécution devient moins chère et plus rapide, le levier se déplace vers la prise de décision en amont de l’exécution
- Des exigences erronées, un problème mal compris ou des hypothèses de conception défectueuses se propagent dans tout ce que l’IA construit, et elles se propagent désormais plus vite
- Plus System 1 devient puissant, plus le coût d’un mauvais usage de System 2 augmente
L’illusion de la vitesse
- Vieille blague du monde académique : « Ce qui prendrait quelques heures à la bibliothèque prend plusieurs semaines au laboratoire » ; version logiciel : « Plusieurs semaines de code permettent d’économiser quelques heures de planification »
- L’idée essentielle est qu’en réalité c’est l’inverse : commencer dans la précipitation conduit à découvrir des erreurs fondamentales, puis à subir une refonte douloureuse
- En génie logiciel, il existe une intuition claire : il faut détecter les erreurs le plus tôt possible, idéalement au stade des exigences ou de la conception
- Un diagramme de boîtes se modifie facilement, une exigence mal comprise est plus difficile à corriger, et une architecture de déploiement fondamentalement défaillante exige pratiquement une réécriture
- Le problème avec l’IA : elle peut générer de la dette technique plus vite que jamais
- Si les décisions prises avant l’exécution sont défectueuses, l’IA mettra fidèlement en œuvre ces défauts sous une forme qui ressemble à du code fonctionnel complet
- Elle peut générer des milliers de lignes de code à partir d’exigences mal comprises et construire volontiers une solution élégante à un mauvais problème
- L’illusion de la vitesse : on a l’impression d’avancer alors qu’en réalité on creuse simplement plus profond
- La bonne réponse n’est pas d’abandonner la vitesse, mais de la déployer intentionnellement : la rapidité de l’IA ne doit être mobilisée qu’une fois la bonne direction confirmée
Quand la lenteur devient efficace
- Les points où la lenteur délibérée produit le plus d’effet n’ont pas vraiment changé
- Modifier des exigences coûte peu quand elles ne sont encore que des mots dans un document, et très cher quand elles sont déjà dans du code déployé utilisé par de vrais utilisateurs
- Les décisions de conception sont faciles à corriger sur un diagramme, mais difficiles à modifier dans un système en production
- L’IA n’a pas changé cette physique fondamentale ; elle a simplement augmenté le levier quand on s’y prend correctement
- Le protocole Thinking First : avant de confier une tâche à l’IA, le moyen le moins coûteux de détecter une erreur consiste à investir du temps pour clarifier ce que l’on veut réellement
- Paradoxe intéressant : l’IA ne sert pas seulement à accélérer l’exécution, elle peut aussi accélérer la réflexion elle-même
- Clarification des exigences avant le code : consacrer 10 minutes à écrire le problème à résoudre, les critères de réussite et les contraintes, puis faire relire cela par l’IA avant de générer quoi que ce soit
- Exécuter un pré-mortem : avant de figer une conception, demander à l’IA « Qu’est-ce qui pourrait mal tourner avec cette approche ? » pour faire émerger des risques qu’on n’avait pas vus
- Inverser le problème (Invert) : demander à l’IA « Qu’est-ce qui ferait échouer ce projet ? » afin de révéler des hypothèses cachées
- Construire un prototype jetable : le réaliser en quelques heures avec l’IA, le montrer aux parties prenantes et vérifier la compréhension avant d’investir — utiliser la vitesse au service de la lenteur
- Créer un outil interne sommaire : avant d’investir dans le vrai produit, fabriquer d’abord avec l’IA une version grossière pour distinguer ce qui est réellement nécessaire de ce qui ne l’est pas
- Faire émerger tôt les cas limites : avant même de commencer l’implémentation, demander à l’IA de générer les cas limites et les modes de défaillance de la conception afin de les traiter au stade du diagramme
Les nouveaux vents contraires culturels
- « Il suffit d’utiliser l’IA, non ? » est une nouvelle forme de pression sur la vitesse, particulièrement dangereuse parce qu’elle confond apparence de productivité et débit réel
- L’IA peut générer du code en quelques secondes, mais générer du code et résoudre le bon problème ne sont pas la même chose
- Stratégies de réponse :
- Partager explicitement l’étape en cours : si l’on est dans une phase lente, expliquer que l’on clarifie les exigences, que l’on réfléchit aux cas limites ou que l’on vérifie que l’on traite le bon problème
- Faire participer les parties prenantes : intégrer leurs retours coûte peu maintenant, et coûtera cher plus tard
- Montrer le travail en cours : documents d’exigences, croquis de conception, résultats de pré-mortem — rendre visibles les livrables des phases lentes pour prouver que le travail avance
- Définir un timebox pour les étapes lentes : fixer des bornes claires comme « deux jours de clarification des exigences avant d’écrire du code » pour que la lenteur délibérée paraisse planifiée plutôt qu’ouverte
- Partager les apprentissages : faire de brèves mises à jour sur les cas limites découverts ou les hypothèses invalidées pour transformer la phase lente en flux visible de valeur
- Montrer des quick wins : produire tôt un prototype jetable ou une maquette pour prouver que l’on peut avancer vite, et ainsi gagner la confiance nécessaire au travail lent et soigné
- Cela rappelle le concept de Hill Chart de la méthode Shape Up de Basecamp
- Montée : phase lente où l’incertitude est forte et où l’on découvre la véritable nature du travail
- Descente : phase rapide où le chemin est clair et où il ne reste plus qu’à exécuter
- Ce n’est pas une excuse pour retarder, mais une description de la manière dont le bon travail se fait réellement — à long terme, les équipes qui livrent le plus vite sont souvent celles qui savent ralentir au bon moment
Comment passer à l’action
- À essayer avant votre prochaine tâche assistée par l’IA :
- Prenez 10 minutes pour écrire le problème que vous cherchez réellement à résoudre, puis définissez à quoi ressemble le succès et ce qui est hors périmètre
- Avant de commencer à construire, demandez à l’IA d’exécuter un pré-mortem sur l’approche
- Si le travail est d’une certaine ampleur, construisez d’abord un prototype jetable pour valider la direction
Conclusion
- Vitesse et lenteur ne sont pas opposées, ce sont des outils pour des étapes différentes
- L’IA est efficace dans les deux cas : exécution rapide quand la direction est claire, réflexion accélérée quand elle ne l’est pas
- La compétence clé consiste à savoir dans quelle phase on se trouve et à appliquer le bon tempo
Aucun commentaire pour le moment.