Le billet analyse les échecs récents de délégation à l’IA (chatbot BMW proposant un rachat au centime près, boutique gérée par une IA, inventaire Starbucks) et souligne que le vrai risque ne réside pas dans le code généré, mais dans les couches supérieures : architecture, direction et prise de décision autonome. L’auteur distingue trois niveaux de délégation, du plus contrôlé (vibe coding avec relecture du code) au plus dangereux (décision exécutée sans supervision humaine), où les garde-fous traditionnels (revues de code, CI) deviennent inefficaces.
Les exemples illustrent comment des erreurs d’architecture ou de décision, invisibles dans un diff, peuvent avoir des conséquences graves en production, comme le chatbot BMW qui a engagé la concession sans validation humaine. Les outils de développement, en automatisant davantage, risquent de reproduire ces dérives en descendant eux-mêmes les marches de la délégation, sans filet adapté.
L’auteur plaide pour une refonte des garde-fous, non plus centrés sur la relecture du code, mais sur la supervision des décisions et de l’architecture, là où l’IA agit sans retour possible. La solution passe par une réintroduction systématique de l’humain dans les processus critiques, comme l’a fait BMW après l’incident.
L'article explore les distinctions cruciales entre les données brutes, les résultats et les insights dans le domaine de l'expérience utilisateur. Il souligne l'importance de transformer les observations en informations exploitables pour influencer les décisions stratégiques. L'article aborde également la question de la signification statistique dans la recherche UX, un sujet souvent source de confusion. Enfin, il propose des conseils pratiques pour communiquer efficacement les résultats de la recherche UX aux parties prenantes.
Tout est dans le titre
Un article très intéressant que l'on pourrait résumer en 4 étapes pour la prise de décisions "risquées" (passer un concours, choix d'études, etc.) :
1) Quelle est la probabilité de succès ?
2) Qu'est ce qui me différencie de mes compétiteurs ?
3) Quels sont les résultats en cas de non succès ? Ce n'est pas forcément un échec total - par exemple, échouer à un concours pour rentrer dans une grande école permet malgré tout de développer ses connaissances... et d'intégrer une autre grande école peut-être ?
4) Qu'est-ce que je perds si j'échoue ?
Toujours la série d'articles sur l'architecture logicielle