Le battage médiatique est venu en premier. Ensuite l'architecture. Puis les échecs. Les entreprises européennes viennent ensuite, et la plupart d’entre elles ne le savent pas encore.
Ce n’est pas de la spéculation. L’effondrement de Knight Capital est un fait connu du public. L’abandon du NHS NPfIT a été disséqué lors d’auditions parlementaires pendant des années. Médibanque. BST. Hershey. Chacun d’eux a étudié. Rien de tout cela n’empêche la société suivante d’entrer dans la même pièce et de passer le même appel.
Le problème n'est pas l'ignorance. C'est une certitude. Chaque organisation estime que sa situation est différente.
Trois endroits où un système tombe en panne
Lorsqu’un projet d’IA échoue, vous entendrez parler des symptômes. Les données étaient désordonnées. Le modèle a sous-performé. Le déploiement a été précipité. Ce n’est pas l’échec. Voilà à quoi ressemblait l’échec à la sortie.
L’échec était structurel. Il a été intégré avant l’exécution de la première ligne de code.
Cela se produit à trois endroits.
La première est la couche de données et de connaissances. C’est ce que sait réellement un système ; pas ce qu'on lui avait dit qu'il savait. SelonGartner, 2018, jusqu'en 2022, 85 % des projets d'IA produiront des résultats erronés en raison de biais dans les données, les algorithmes ou les équipes chargées de les gérer. Ce chiffre ne concerne pas les entreprises négligentes. Il s’agit d’ingénieurs à qui on a remis des données dont on leur avait dit qu’elles étaient prêtes pour la production. Ce n’était pas le cas. Personne n'a vérifié. Le cycle de battage médiatique avait déjà fait avancer la pièce. Le modèle a couru. Il a produit des résultats. Les sorties étaient fausses. Et pendant un moment, personne ne l’a remarqué.
La seconde est la couche de traitement, où les grands modèles de langage et les algorithmes d’inférence transforment les données en décisions. Ces systèmes n’échouent pas bruyamment. Un système qui hallucine ne s’arrête pas. Cela continue. Il produit des réponses qui semblent raisonnables. En 2012,Groupe Knight Capitalperdu 440 millions de dollars en 45 minutes. Pas parce qu’un système est tombé en panne. Parce qu'un système fonctionnait parfaitement, traitant des transactions en direct par rapport à une configuration qui aurait dû être désactivée. C'était confiant. C'était rapide. C'était faux. Personne dans la pièce ne le savait jusqu'à ce que l'argent disparaisse.
La troisième est la couche de mise en œuvre, où les décisions d'un système parviennent aux personnes réelles. De vrais flux de travail. De vrais patients. De vraies conséquences.
LeProgramme national du NHSpour l'informatique a dépensé environ 9,8 milliards de livres sterling sur une décennie. La technologie a fonctionné pour la plupart. Ce qui n’a pas fonctionné, c’est l’hypothèse selon laquelle les flux de travail cliniques de dizaines de trusts du NHS, chacun avec sa propre réalité opérationnelle, son propre personnel, ses propres patients, pourraient être forcés dans un seul système standardisé sans mécanisme permettant à ces personnes de dire : cela ne correspond pas à notre façon de travailler. Il n’y avait pas de boucle de rétroaction. Le système n’a pas pu comprendre qu’il ne répondait pas aux besoins des personnes pour lesquelles il avait été construit, car personne n’avait construit un moyen pour que ce signal puisse se propager. Les infirmières ont contourné ce problème. Les médecins ont documenté deux fois. Les patients tombaient dans les brèches. Finalement, le programme a été abandonné. Les 9,8 milliards de livres sterling avaient disparu.
Les organisations du secteur public européen qui gèrent aujourd’hui des programmes de numérisation des soins de santé partent de la même hypothèse. Pas le même système. La même hypothèse.
SelonMcKinsey, 70 % des transformations à grande échelle échouent. Les raisons qu’ils avancent – objectifs peu clairs, faible engagement, aucun investissement dans les capacités – sont autant de descriptions de ce qui se passe lorsque les organisations décident de se lancer avant d’être prêtes à construire. C'est un problème de battage médiatique. Ce n'est pas un problème technologique.
La version européenne coûte plus cher
Une entreprise américaine qui rencontre une défaillance au niveau de la livraison entre en phase de remédiation. Une entreprise européenne qui rencontre le même échec en vertu du RGPD, de DORA ou de la loi européenne sur l’IA entre en même temps dans une mesure corrective et dans une enquête réglementaire.
L’environnement d’application ici est différent. La plupart des études de cas que les gens lisent ont été rédigées par des organisations qui n’ont jamais fonctionné dans ce cadre.
C’est important car cela modifie le coût de la deuxième erreur, pas seulement de la première. Une mauvaise couche de données au cours de la première année est récupérable. Découvrir que la couche de livraison enregistre des sorties non conformes depuis dix-huit mois, alors que le régulateur pose des questions, est une situation totalement différente.
Calsoft s'appuie sur les trois couches en tant qu'exigences de conception, et non après coup. La qualité, la traçabilité et l'exactitude contextuelle de la couche de données et de connaissances sont vérifiées avant que quoi que ce soit d'autre ne soit exécuté. La couche de traitement est régie par le risque d'hallucination et la responsabilité des résultats, et pas seulement par la vitesse. La couche de livraison est conçue avec l’auditabilité comme caractéristique structurelle. Pour les entreprises de l’UE qui opèrent dans des délais d’application réels, cela ne constitue pas un facteur de différenciation. C'est l'architecture minimale viable.
Une question avant la prochaine signature
La chose la plus utile qu'un CTO puisse faire avec un échec documenté est de ne pas le transmettre à l'équipe. Posez une question lors de la prochaine révision de l’architecture : quelle décision, prise différemment, aurait changé le résultat ?
Vérifiez ensuite si cette décision est sur la table dès maintenant.
C’est généralement le cas. La différence est de savoir si quelqu’un a suffisamment d’autorité et assez de patience pour ralentir les choses suffisamment longtemps pour y arriver.
FAQ
Quelles défaillances technologiques mondiales les entreprises de l’UE devraient-elles étudier le plus ?
Les échecs dans le déploiement de modèles d’IA, les plateformes de données à grande échelle et le déploiement de systèmes d’entreprise sont les plus instructifs. Ils impliquent les mêmes infrastructures que les entreprises européennes construisent actuellement. Ils échouent selon les mêmes schémas : lacunes en matière de gouvernance des données, dérive de traitement, hypothèses de livraison jamais testées par rapport aux conditions opérationnelles réelles, quels que soient le secteur, la zone géographique ou la taille du budget.
Comment la réglementation européenne change-t-elle ce que les entreprises devraient tirer des cas de faillite mondiale ?
La plupart des échecs documentés se sont produits sur des marchés où une erreur de traitement des données impliquait une correction technique. En vertu du RGPD, du DORA et de la loi européenne sur l'IA, la même erreur peut signifier une action réglementaire sans aucune panne visible. La leçon technique d’une étude de cas mondiale est généralement transférée. Souvent, la conséquence de heurter le même mur n’a pas d’effet.
Une culture post-mortem interne est-elle suffisante ?
Non. Les analyses post-mortem documentent les échecs auxquels votre organisation a survécu. Ils ne peuvent pas faire apparaître les risques dans les systèmes que vous n’avez pas encore construits. Et ils excluent les échecs suffisamment graves pour mettre fin aux organisations – parce que ces organisations n’écrivent pas vos rétrospectives. L’analyse des échecs externes couvre la catégorie de risque que l’apprentissage interne ne peut atteindre.
