HumanSlop : comment une entreprise de 110 milliards de dollars livre-t-elle un logiciel aussi mauvais ?
Nous moquons le « slop » de l’IA pendant que d’immenses organisations humaines produisent le leur depuis des décennies.
· Matt Senter
On s’inquiète beaucoup, ces temps-ci, du « slop » produit par l’IA.
Des sites générés par IA. Du code généré par IA. Du contenu généré par IA. Des interfaces qui semblent à peu près correctes jusqu’au moment où l’on essaie de s’en servir. Des fonctionnalités qui existent techniquement mais que personne n’a manifestement réfléchies. Des produits qui donnent l’impression que quelqu’un a tapé un prompt, jeté un œil au résultat et publié.
Une bonne partie de cette critique est méritée. Mais les humains produisent du logiciel déplorable depuis des décennies, et parfois avec des moyens qu’une startup d’IA aurait du mal à imaginer.
Je suis tombé récemment sur un exemple particulièrement beau chez Enbridge, une entreprise dont la capitalisation boursière tournait autour de 110 milliards de dollars au moment où je l’ai vérifiée.
Arrêtons-nous un instant sur ce chiffre.
Cent dix milliards de dollars.
Imaginez ce que vous pourriez construire avec ne serait-ce qu’une fraction minuscule des ressources d’une organisation de cette taille. Vous pourriez recruter des ingénieurs d’élite partout dans le monde. Vous pourriez entretenir des équipes dédiées au produit, au design, à la sécurité, à l’accessibilité, à la qualité, à l’infrastructure et à l’expérience client. Vous pourriez tester chaque parcours sur tous les navigateurs, appareils, réseaux de paiement et méthodes d’authentification qui comptent. Vous pourriez enchaîner les études d’utilisabilité jusqu’à en avoir assez.
Vous pourriez construire un site extraordinaire.
À la place, Enbridge en a construit un qui refuse un mot de passe de plus de 13 caractères.
Ça, c’est du HumanSlop.
Mon fournisseur de gaz a « modernisé » son site
Je me suis retrouvé sur le nouveau site d’Enbridge parce que j’ai reçu un avis m’indiquant que le paiement en ligne de ma facture via ma banque avait été annulé. J’avais déjà un moyen parfaitement fonctionnel de payer mon gaz, mais Enbridge a changé quelque chose de son côté et m’a forcé à migrer.
Soit. Les systèmes évoluent.
Je suis allé sur le nouveau site, j’ai voulu créer mon compte, et voici ce qui m’a accueilli :
Le mot de passe ne peut pas dépasser 13 caractères.
Treize caractères.
En 2026.
Nous passons des années à expliquer aux gens d’utiliser un gestionnaire de mots de passe, de générer des mots de passe longs et aléatoires, et d’arrêter de réutiliser de courts identifiants mémorisables. Mon gestionnaire a fait exactement son travail et généré un mot de passe robuste. Le tout nouveau système d’Enbridge a répondu, en substance :
Hé, hé, hé. Pas si sécurisé que ça.
Ce n’est pas une vieille application à écran vert posée devant un mainframe. C’est le nouveau site client de l’une des plus grandes entreprises d’infrastructure énergétique d’Amérique du Nord.
Repensez encore aux moyens en jeu. Une entreprise de cette taille peut s’offrir une infrastructure d’identité sophistiquée, des tests d’intrusion, des consultants en sécurité, des suites de tests automatisés, des ingénieurs sécurité dédiés et le fournisseur d’authentification de son choix.
Quelque part dans toute cette machinerie, la réponse finale a été :
Longueur maximale du mot de passe : 13. On livre.
Et puis il y a le design
Avant même de tomber sur les bugs, le site a l’air d’avoir été récupéré dans une migration SharePoint de 2003.
Regardez-le.
Un énorme en-tête gris. De minuscules champs de formulaire. Des liens bleus soulignés. Un encadré latéral avec « Se connecter » et « Nous contacter ». Des blocs d’instructions compacts. Des bordures dures. De tout petits boutons. Des choix de mise en page qui évoquent moins un portail client moderne qu’un guichet d’aide sociale municipal en 1998.
Et pourtant la page annonce fièrement :
« Bienvenue dans votre nouvelle expérience en ligne ! »
Cette phrase est peut-être ce qu’il y a de plus drôle dans toute l’histoire.
Nouvelle par rapport à quoi ? À Telnet ?
Il s’agit d’une entreprise qui vaut environ 110 milliards de dollars, et sa « nouvelle expérience en ligne » ressemble au genre de site où l’on s’attend à voir une balise <marquee> clignotante et un badge « Optimisé pour Internet Explorer 6 » en bas de page.
Le problème n’est pas que chaque site d’entreprise doive ressembler à Apple. Ce n’est pas nécessaire. Un portail de facturation de service public devrait être ennuyeux. Il devrait être clair, rapide, évident, accessible et presque impossible à rater.
Mais ce n’est pas ennuyeux dans le bon sens. Il paraît vieux parce que l’architecture de l’information, la typographie, la hiérarchie, les espacements, les contrôles et les schémas d’interaction sont tous anciens.
Et encore une fois :
110 milliards de dollars.
Imaginez avoir un seul milliard de dollars pour faire du logiciel.
Vous pourriez recruter certains des meilleurs designers produit du monde. Vous pourriez bâtir un design system valable sur tous les points de contact client. Vous pourriez tester le portail avec des milliers de vrais clients. Vous pourriez rendre la connexion évidente. Vous pourriez rendre l’interface de facturation excellente sur ordinateur et sur mobile. Vous pourriez vous acharner sur l’accessibilité, la performance et l’utilisabilité jusqu’à ce qu’il ne reste presque rien à améliorer.
Il ne faudrait évidemment pas un milliard pour tout cela. Vous pourriez construire une version radicalement meilleure de cette page avec une fraction infime de cette somme.
C’est justement ce qui rend la chose si drôle.
Ce n’est pas l’histoire d’une entreprise à court de moyens.
C’est l’histoire de ce qui arrive quand les ressources cessent d’être le facteur limitant et que la qualité organisationnelle le devient.
Puis le site a cessé de fonctionner
Après avoir contourné la contrainte de mot de passe, j’ai commencé à recevoir des échecs génériques :
« Il y a un problème de notre côté. Patientez quelques minutes et réessayez. »
C’est agaçant sur n’importe quel site, mais le contexte aggrave les choses. Je ne me suis pas porté volontaire pour tester la passionnante nouvelle expérience numérique d’Enbridge. Mon ancien parcours de paiement fonctionnait. Enbridge l’a supprimé et m’a redirigé vers le remplaçant.
Si vous imposez une migration à vos clients, le remplaçant devrait fonctionner.
Cela ne devrait pas être une philosophie produit controversée, surtout quand l’entreprise qui impose la migration vaut onze chiffres.
L’entreprise à 110 milliards qui a oublié comment marche American Express
J’ai fini par atteindre le formulaire de carte bancaire. Enbridge affichait American Express parmi les cartes acceptées, j’ai donc saisi mes informations Amex.
Puis je suis arrivé au champ du cryptogramme.
American Express utilise un code de sécurité à quatre chiffres.
Le formulaire d’Enbridge en autorisait trois.
J’ai saisi trois chiffres et tenté d’en taper un quatrième. Rien. Le champ l’a simplement refusé.
C’est mon bug préféré tant il est magnifiquement simple.
Aucun cas limite subtil à déboguer. Aucune situation de compétition cachée dans un système distribué. Aucune incompatibilité obscure de navigateur qui n’apparaît que le mardi quand Mercure est rétrograde.
Les cartes American Express ont un code de sécurité à quatre chiffres.
Si vous annoncez accepter American Express, votre formulaire doit accepter quatre chiffres.
C’est toute l’exigence.
Un développeur junior le comprendrait. Un testeur le repérerait. Un test d’intégration automatisé le repérerait. Un chef de produit payant son déjeuner avec une Amex le repérerait.
Et pourtant ce bug a traversé toute la machinerie d’ingénierie, de prestataires, de design, de QA, de sécurité, de déploiement et de validation d’une entreprise à 110 milliards, et il est ressorti vivant de l’autre côté.
Il faut le faire.
Sérieusement, imaginez ce que vous pourriez construire avec un milliard
Un milliard de dollars est un nombre si grand qu’il en devient abstrait, alors oubliez un instant la valorisation de 110 milliards d’Enbridge.
Imaginez qu’on vous tende un milliard de dollars en vous disant :
Construisez la meilleure expérience client de service public sur Terre.
Que pourriez-vous construire ?
Vous pourriez recruter 500 ingénieurs exceptionnels à 250 000 dollars par an et les employer pendant huit ans.
Vous pourriez monter des équipes dédiées au design produit, au frontend, au backend, à la sécurité, à l’accessibilité, à la fiabilité, au mobile, aux paiements, à la recherche client, à l’analytique, à la QA et à l’infrastructure.
Vous pourriez bâtir des environnements de test à pleine échelle reproduisant la production.
Vous pourriez tester chaque moyen de paiement. Chaque navigateur. Chaque téléphone. Chaque scénario d’accessibilité. Chaque parcours d’authentification.
Vous pourriez payer de vrais clients pour passer la journée à essayer de casser le site. Vous pourriez mener des études d’utilisabilité auprès de tous les publics que vous servez. Vous pourriez recruter des spécialistes pour garantir qu’une personne malvoyante, à mobilité réduite ou peu à l’aise avec la technique puisse payer sa facture de gaz sans s’énerver.
Vous pourriez faire une application. Vous pourriez faire une expérience web de premier ordre. Vous pourriez construire des API. Vous pourriez créer des prévisions de facturation en temps réel, des analyses de consommation, des informations sur les coupures, des réglages de prélèvement automatique, le partage de compte, des alertes, des notifications et des intégrations avec tous les portefeuilles numériques majeurs.
Vous pourriez probablement reconstruire toute la plateforme plusieurs fois.
Et après tout cela, il vous resterait encore des centaines de millions.
Rappelez-vous maintenant qu’Enbridge vaut environ 110 fois cette somme.
La capitalisation boursière n’est évidemment pas de la trésorerie. Enbridge n’a pas 110 milliards dans un coffre en attendant que quelqu’un les dépense sur des champs de mot de passe. Ce n’est pas la question.
La question, c’est l’échelle.
Nous ne parlons pas d’un fondateur avec 40 000 dollars en banque qui essaie de garder ses serveurs allumés.
Nous parlons d’une immense entreprise disposant d’un accès quasi illimité aux expertises nécessaires pour résoudre ces problèmes.
Et le résultat est un site qui paraît vieux de plusieurs décennies, refuse les mots de passe modernes, renvoie des erreurs serveur génériques et prétend accepter American Express tout en refusant un cryptogramme American Express.
Ce n’est pas un problème de ressources.
C’est du Human Slop.
Plus de process ne produit pas forcément un meilleur logiciel
L’une des hypothèses les plus étranges du développement logiciel est que davantage de process organisationnel mène naturellement à davantage de qualité.
Une entreprise géante dispose vraisemblablement de chefs de produit, de chefs de projet, d’ingénieurs, de designers, d’équipes sécurité, d’équipes QA, de prestataires externes, de consultants, de process de conformité, d’environnements de préproduction, de procédures de déploiement, d’outils de tickets et de chaînes de validation. Tout cela devrait en théorie fiabiliser quelque chose comme un formulaire de paiement.
Mais la complexité dilue aussi la responsabilité.
L’équipe authentification possède un morceau. Le prestataire de paiement un autre. Une équipe frontend possède le formulaire. Un design system impose le composant. La sécurité pose ses exigences. Le produit a rédigé les critères d’acceptation. La QA a testé les cas documentés. Un prestataire a construit une partie de l’ensemble.
Chacun peut faire correctement la tâche qui lui a été confiée pendant que le produit final reste mauvais.
C’est cette partie que je trouve intéressante.
Personne n’a nécessairement décidé de construire quelque chose de stupide. C’est l’organisation qui a produit la stupidité collectivement.
Un système peut traverser des couches de revue humaine, de planification, de réunions, de tests, d’achats et de validations, et arriver malgré tout en production incapable d’accepter le code de sécurité de l’une des cartes qu’il prétend accepter.
L’argent achète du talent, mais il ne garantit pas la responsabilité.
L’argent achète du process, mais il ne garantit pas le jugement.
L’argent achète des équipes QA, mais il ne garantit pas que quelqu’un ait testé l’évidence.
Parfois, tout ce process ne fait que rendre le slop plus cher.
Le slop de l’IA a au moins une excuse
C’est aussi pour cela qu’une partie de l’indignation autour du logiciel généré par IA m’amuse. Nous jugeons une technologie qui existe depuis quelques années à l’aune d’organisations logicielles humaines qui ont eu des décennies pour comprendre tout cela.
Bien sûr que l’IA produit parfois du mauvais code. Bien sûr qu’un agent peut mal comprendre une exigence. Bien sûr que des interfaces générées peuvent contenir des hypothèses bizarres. Ce sont de vrais problèmes, et le logiciel généré par IA doit absolument être testé avant d’atteindre les utilisateurs.
Mais quelle est exactement l’excuse quand des centaines ou des milliers d’humains, des pratiques d’ingénierie matures, des budgets énormes et des décennies de savoir institutionnel produisent le même résultat ?
Si un agent de codage produisait un formulaire Amex n’acceptant que trois chiffres, je pourrais sans doute lui dire :
American Express utilise un cryptogramme à quatre chiffres. Corrige cela et ajoute un test de non-régression.
Il y a de bonnes chances que le problème soit réglé quelques minutes plus tard.
L’immense organisation humaine, elle, a réussi à faire entrer le bug jusqu’en production.
Le vrai problème, ce sont les incitations
Il y a une autre raison pour laquelle mon expérience Enbridge m’a gêné plus qu’un mauvais site ordinaire : qu’est-ce que je peux bien y faire ?
Si un site marchand rend le paiement pénible, j’achète ailleurs. Si un produit SaaS se dégrade, je résilie. Si un restaurant me sert mal en permanence, je n’y retourne pas.
La concurrence crée une boucle de rétroaction brutale mais efficace :
Rendez vos clients malheureux assez longtemps et vous finirez par les perdre.
Les services publics fonctionnent autrement.
Je ne peux pas vraiment annoncer que l’expérience utilisateur d’Enbridge me déçoit et demander à une autre entreprise de raccorder son réseau de gaz concurrent à ma maison.
Quel est mon levier ?
« Réparez votre site ou j’emmène mes canalisations de gaz enterrées chez un concurrent » ?
Quand les clients ne peuvent pas partir facilement, l’un des mécanismes les plus puissants pour sanctionner le mauvais logiciel disparaît.
Cela ne veut pas dire que quelqu’un chez Enbridge a délibérément décidé que l’expérience client n’avait pas d’importance. Je suis sûr que beaucoup de gens y tiennent beaucoup à bien faire. Mais les incitations comptent, même quand personne n’en parle explicitement.
Si vous ne pouvez pas perdre le client, la pression pour l’enchanter n’est tout simplement pas la même.
Et parfois, on sent cette absence dans le produit.
Ce ne sont pas des problèmes difficiles
C’est peut-être ce qui me dérange le plus.
Aucune de mes récriminations ne relève d’une ingénierie difficile.
Je ne demande pas à Enbridge de résoudre la fusion nucléaire.
Je lui demande de :
- Autoriser des mots de passe de longueur moderne.
- Maintenir son site en état de marche.
- Accepter quatre chiffres dans un champ à quatre chiffres.
- Construire un portail client qui n’ait pas l’air vieux de plusieurs décennies.
- Tester le système de facturation avant d’y forcer la migration des clients.
Ce sont des problèmes résolus.
Un développeur compétent pourrait en corriger plusieurs avant le déjeuner. Une équipe design compétente pourrait moderniser toute l’interface sans rien réinventer. Un process QA compétent devrait détecter le bug Amex immédiatement.
Et pourtant tout cela a survécu jusqu’en production dans une entreprise qui vaut des dizaines de milliards.
Cela devrait nous faire reconsidérer l’idée que la principale menace pour la qualité logicielle serait des développeurs inexpérimentés armés d’IA.
Parfois, le développeur inexpérimenté avec un agent d’IA remarquerait justement le problème du cryptogramme à quatre chiffres.
Les humains n’ont pas de dispense de qualité
Le développement logiciel assisté par IA m’enthousiasme. Je pense aussi que nous devons être extrêmement critiques envers les déchets qu’il peut produire. Ces deux positions sont parfaitement compatibles.
Le code généré doit être relu. Les agents ont besoin de tests. Les interfaces créées par IA ont besoin de vrais utilisateurs. Les entreprises ne devraient pas livrer de la camelote simplement parce qu’il est devenu moins cher d’en produire.
Mais l’exigence doit valoir dans les deux sens.
Un logiciel ne devrait pas bénéficier d’une dispense de qualité simplement parce qu’un modèle a aidé à le construire.
Et un logiciel ne devrait pas bénéficier d’une dispense de qualité simplement parce que des humains l’ont construit.
Si nous nous moquons des systèmes d’IA pour des formulaires cassés, une UX absurde, des erreurs de sécurité et des fonctionnalités visiblement non testées, nous devrions appliquer exactement le même standard aux organisations logicielles traditionnelles.
Peut-être même un standard plus élevé.
Le slop de l’IA est produit par une technologie que nous cherchons encore à comprendre.
Le slop humain est produit après des décennies passées à savoir mieux faire.
La prochaine fois que quelqu’un me montrera une application générée par IA ridicule comme preuve qu’on ne peut pas confier la construction de logiciels aux machines, je repenserai à cette entreprise valant environ 110 milliards de dollars dont le nouveau site de facturation a trouvé mon mot de passe sécurisé trop long, dont la « nouvelle expérience en ligne » semblait avoir survécu au bug de l’an 2000, et dont le formulaire de paiement estimait que mon cryptogramme American Express à quatre chiffres devait tenir dans trois.
Imaginez ce que vous pourriez construire avec un milliard de dollars.
Puis imaginez avoir accès aux ressources d’une organisation qui vaut 110 fois cela, et livrer ceci.