Klarna a remplacé 700 personnes par une IA. Puis les a toutes réembauchées. Voici ce que toute entreprise devrait en retenir.

J'étais en pleine réunion téléphonique avec un client bancaire potentiel quand la nouvelle Klarna est tombée. Mi-2025. Mon téléphone a vibré — un collègue m'avait transféré l'article avec une seule phrase : « C'est littéralement ce que tu répètes depuis des années. »

Le client était en train de m'expliquer comment ils avaient construit un chatbot de service client par-dessus GPT-4, et à quel point « ça marchait très bien ». Je lui ai demandé à quoi ressemblaient leurs scores de CSAT. Long silence. « On ne les suit pas encore. »

Ce silence m'a tout dit. Parce que Klarna, lui, avait suivi ces indicateurs. Et ce qu'ils y ont découvert était assez accablant pour revenir sur l'un des déploiements d'IA les plus médiatisés de l'histoire de la fintech.

Voici la version courte : Klarna, le géant suédois du paiement fractionné valorisé 14,6 milliards de dollars, a remplacé environ 700 conseillers du service client par un assistant IA construit sur OpenAI. L'annonce ressemblait à un tour d'honneur — l'IA traitait 75 % de toutes les conversations clients, en 35 langues. Le coût par transaction a chuté de 40 %. Wall Street a adoré. Puis les scores de satisfaction client ont baissé de 22 %. L'entreprise a affiché une perte nette de 99 millions de dollars au premier trimestre 2025. Et le PDG Sebastian Siemiatkowski a reconnu publiquement que la course à l'efficacité avait vidé la qualité de service de sa substance, produisant des réponses qu'il a qualifiées de « génériques » et incapables de traiter quoi que ce soit exigeant un véritable discernement.

Ils ont recommencé à recruter. Ils ont même réaffecté des ingénieurs logiciels et des marketeurs pour répondre au téléphone.

Je construis des systèmes d'IA neuro-symbolique chez Veriprajna depuis des années maintenant, et j'ai vu entreprise après entreprise tomber dans le même piège. Non pas parce que la technologie est mauvaise — les grands modèles de langage sont véritablement remarquables. Mais parce qu'il existe une confusion fondamentale entre avoir l'air juste et être juste, et, dans les secteurs réglementés, cette confusion finit par tout vous coûter.

La nuit où j'ai compris qu'« assez bien » ne suffit pas

Avant d'entrer dans l'architecture, je veux vous raconter un moment qui a changé ma façon de voir ce problème.

Nous menions un pilote pour un système de conformité juridique — pas du service client, mais de l'analyse documentaire. Le genre de travail où l'on décortique des dépôts réglementaires et où l'on met en correspondance des politiques internes avec des obligations externes. Nous avions un prototype qui utilisait un montage classique de retrieval-augmented generation. Recherche vectorielle, récupération top-k, GPT qui génère le résumé. C'était rapide. Les sorties se lisaient à merveille.

L'une de nos ingénieures — Priya — est restée tard à passer des cas limites. Vers 23 h, elle a posté une capture d'écran sur notre canal Slack. Le système avait généré un paragraphe parfaitement fluide citant une clause réglementaire précise. La clause n'existait pas. Pas une citation erronée, pas une paraphrase — une fabrication complète. Et c'était rédigé de façon si convaincante que, sans être expert de cette réglementation précise, vous ne l'auriez jamais repéré.

Je me revois à mon bureau, fixant cette capture d'écran, en me disant : c'est ça, le produit qu'on s'apprête à livrer. Un système qui ment avec l'assurance d'un associé principal de cabinet d'avocats.

Nous avons arrêté le pilote. Reconstruit l'architecture de zéro. Perdu trois mois. C'est la meilleure décision que nous ayons jamais prise.

Quand un système d'IA fabrique une citation juridique avec une confiance parfaite, le problème n'est pas un bug — c'est l'architecture. Aucun prompt engineering ne vous sortira d'une fondation fondamentalement probabiliste.

Qu'est-ce que le « piège du wrapper » et pourquoi continue-t-il de piéger des entreprises intelligentes ?

Laissez-moi expliquer en termes techniques ce qui est réellement arrivé à Klarna, parce que la presse économique s'est largement trompée. Elle a présenté l'affaire comme « l'IA n'est pas encore prête ». Ce n'est pas le sujet. Le sujet, c'est quel type d'IA et la manière dont elle a été déployée.

Un « wrapper » est une fine couche logicielle posée par-dessus un grand modèle de langage tiers. Elle gère le formatage, orchestre les appels d'API, ajoute peut-être un peu d'analyse de sorties structurées. Mais la réflexion elle-même — le raisonnement, le discernement, la prise de décision — est entièrement sous-traitée au LLM. Votre wrapper envoie un prompt, le modèle prédit les tokens suivants les plus probables, et vous récupérez quelque chose qui ressemble à une réponse.

Ça marche à merveille pour une démo. Ça marche correctement pour des tâches à faible enjeu. Et ça échoue catastrophiquement dès qu'il faut de la certitude.

L'architecture Transformer qui anime ces modèles utilise un mécanisme d'auto-attention pour pondérer la pertinence des tokens d'une séquence et prédire la suite. C'est de la reconnaissance de motifs — une reconnaissance de motifs extraordinairement sophistiquée, mais de la reconnaissance de motifs tout de même. Il n'existe aucun mécanisme interne permettant de vérifier des faits par rapport à une source de vérité externe. Le modèle ne sait rien. Il prédit ce à quoi une réponse informée ressemblerait.

L'IA de Klarna savait réinitialiser des mots de passe sans la moindre faute. Mais quand un client avait un litige complexe impliquant un remboursement partiel, un désaccord avec un marchand et des réglementations de protection des consommateurs dans deux juridictions ? Le modèle se rabattait sur ce que j'appelle le slop-spinning — générer des réponses plausibles qui tournent en rond, ne résolvent jamais rien et exaspèrent les clients jusque dans ce qu'un analyste a décrit comme une « boucle kafkaïenne ».

Et voici la partie qui devrait terrifier tout dirigeant d'entreprise : les indicateurs de coûts avaient l'air excellents pendant tout le temps où l'expérience se dégradait. Le coût par transaction est passé de 0,32 $ à 0,19 $. Le temps de résolution d'une conversation est passé de 11 minutes à moins de 2. Si vous ne regardiez que le tableau de bord, vous auriez cru gagner — jusqu'à l'instant précis où vos clients ont commencé à partir.

Pourquoi ne peut-on pas simplement ajouter de meilleurs garde-fous à un LLM ?

C'est la question qu'on me pose le plus souvent, et elle révèle le malentendu de fond. Les gens pensent que la solution passe par de meilleurs prompts, davantage d'exemples few-shot, des instructions système plus serrées. « Il suffit de dire au modèle de ne pas halluciner. »

C'est comme dire à un modèle de prévision météo de ne pas se tromper. La nature probabiliste n'est pas un défaut à corriger — c'est le mécanisme fondamental du fonctionnement du système.

Un investisseur m'a dit un jour, de but en blanc : « Utilisez simplement GPT et ajoutez quelques règles par-dessus. » Je lui ai demandé s'il ferait confiance à une calculatrice juste 95 % du temps. Il a ri. Je lui ai dit : « C'est exactement ce que vous proposez pour la conformité bancaire. » Il a arrêté de rire.

Les modes de défaillance technique vont plus loin que l'hallucination. Les wrappers n'ont pas ce que j'appellerais la persistance du schéma d'état. À mesure que la conversation avance, la fenêtre de contexte se remplit. Les informations du début de l'échange sont compressées ou abandonnées. Le modèle peut se contredire au sein d'une même session sans avoir la moindre conscience de l'avoir fait. Dans le service client, cela signifie que l'agent peut vérifier votre identité au tour 3 puis vous demander de la vérifier à nouveau au tour 15 — ou pire, sauter complètement la vérification parce que le fil de la conversation l'a « persuadé » qu'elle avait déjà eu lieu.

C'est la vulnérabilité que j'appelle le sophisme de la liberté infinie. Comme le LLM n'a aucune contrainte structurelle dure sur ce qu'il peut dire ou faire, un utilisateur suffisamment habile — ou une situation suffisamment complexe — peut le pousser dans des états qui violent les règles métier, les exigences réglementaires ou la logique la plus élémentaire. On ne résout pas cela par du prompting. Il faut un tout autre type d'architecture.

J'ai traité ce problème en profondeur dans la version interactive de nos travaux de recherche, mais l'idée centrale est simple : il faut séparer la voix du cerveau.

Les 20 % qui font tout basculer

Il y a un schéma que j'observe dans chaque secteur où nous intervenons, et je pense qu'il explique pourquoi tant de déploiements d'IA suivent la trajectoire de Klarna.

En 2025, l'IA sait traiter avec compétence environ 80 % des interactions routinières et à haute fréquence. Réinitialisations de mots de passe, suivis de commande, réponses de base aux FAQ — ce sont des problèmes résolus. Les 20 % d'interactions restantes sont celles qui comptent vraiment. Ce sont les litiges complexes, les cas limites, les moments où un client est agacé, perdu ou inquiet. Et ce sont les principaux moteurs de la réputation de marque et de la responsabilité financière.

Klarna a optimisé pour les 80 % et ignoré les 20 %. Le calcul semblait évident : automatiser le facile, économiser des millions. Mais c'est dans les 20 % que la confiance se construit ou se détruit. Un client dont la réinitialisation de mot de passe se passe sans accroc n'en parle à personne. Un client qui passe 45 minutes coincé dans une boucle d'IA à tenter de résoudre une erreur de facturation en parle à tout le monde.

Les 80 % d'interactions que l'IA traite bien sont invisibles pour votre marque. Les 20 % qu'elle traite mal sont les seules dont on se souvienne.

L'ironie, c'est que les 10 millions de dollars d'économies initiales réalisées par Klarna grâce à la réduction d'effectifs ont presque certainement été éclipsés par la valeur vie client qu'elle a détruite à force d'expériences dégradées. Quand on est une entreprise à 14,6 milliards de dollars qui prépare son introduction en bourse, une chute de 22 % de la satisfaction client n'est pas un problème d'indicateur — c'est un problème existentiel.

Que signifie réellement « IA déterministe » ?

Donc, si les wrappers sont le problème, quelle est la solution ? C'est ici que je dois devenir un peu technique, mais je promets de rester concret.

Chez Veriprajna, nous construisons ce qu'on appelle de l'IA neuro-symbolique. Le nom sonne académique, mais le concept est intuitif : on prend l'aisance langagière d'un réseau de neurones et on la contraint dans la logique rigide d'un moteur de raisonnement symbolique. Le réseau de neurones se charge du travail « souple » — comprendre le langage naturel, générer des réponses lisibles par un humain, interpréter des requêtes ambiguës. Le moteur symbolique se charge du travail « dur » — faire respecter les règles, valider la logique, garantir que chaque sortie est traçable jusqu'à une source vérifiée.

Nous appelons cela le sandwich neuro-symbolique. Avant qu'une requête n'atteigne le LLM, une couche de validation d'intention la confronte aux contraintes de politique interne et filtre les entrées adverses. Une fois que le LLM a généré une réponse, un moteur de validation — typiquement un automate fini ou un solveur logique — vérifie chaque affirmation contre le graphe de connaissances et chaque action contre les règles métier. Si la réponse viole la moindre contrainte, elle ne passe pas. Point.

Nous utilisons une technique appelée décodage contraint — aussi connue sous le nom de masquage de tokens — que je trouve particulièrement élégante. Plutôt que de laisser le modèle générer librement puis de vérifier la sortie, nous empêchons physiquement certains tokens d'être générés dès le départ. Si le modèle produit un rapport de conformité fiscale, la couche symbolique garantit que chaque nombre correspond à un calcul vérifié. Le modèle, littéralement, ne peut pas halluciner un nombre, car les tokens hallucinés sont masqués de la distribution de probabilité avant même que la génération n'ait lieu.

Il ne s'agit pas d'« ajouter des garde-fous ». Il s'agit d'une architecture fondamentalement différente, où le LLM est la voix et le moteur symbolique le cerveau, et où la voix n'a jamais le droit de parler sans l'approbation du cerveau.

Quand le graphe de connaissances nous a évité une erreur à 2 millions de dollars

Le RAG standard — retrieval-augmented generation — a un problème dont la plupart des gens ne parlent pas. Il s'appuie sur la similarité vectorielle pour trouver les documents pertinents. Mais la similarité vectorielle ne comprend pas la directionnalité. « L'entreprise A a poursuivi l'entreprise B » et « L'entreprise B a poursuivi l'entreprise A » peuvent avoir des embeddings vectoriels presque identiques, alors qu'elles décrivent des situations juridiques totalement opposées.

Nous l'avons découvert à la dure lors d'un pilote juridique. Notre système analysait l'historique contentieux d'un client grand compte, et le montage RAG standard confondait sans cesse les rôles de demandeur et de défendeur. Les sorties étaient fluides, bien structurées et dangereusement fausses.

C'est là que nous sommes passés à ce que nous appelons le GraphRAG à citation obligatoire. Au lieu de déverser les documents dans une base vectorielle, nous les analysons pour construire un graphe de connaissances — des entités reliées par des relations typées et orientées. Quand le système avance une affirmation, il doit la faire remonter à des nœuds et des arêtes précis du graphe. Si le graphe ne peut pas étayer l'affirmation, le système ne la formule pas.

Le gain de précision a été spectaculaire — 30 à 35 % de plus que le RAG standard sur les tâches de raisonnement multi-sauts complexes. Mais, plus important encore, cela nous a donné quelque chose qu'aucune dose de prompt engineering ne pouvait offrir : une piste d'audit. Chaque sortie peut être retracée par le chemin de raisonnement exact, d'entité en entité, de relation en relation. Un responsable conformité peut voir pourquoi le système est parvenu à une conclusion, et pas seulement ce qu'il a conclu.

Pour le décryptage technique complet du fonctionnement de cette architecture dans différents domaines — banque, juridique, industrie manufacturière —, voir notre analyse technique approfondie.

La discussion qui a failli diviser mon équipe

Je veux être honnête sur un point. Construire de cette façon est plus difficile. Nettement plus difficile. Et il y a eu un moment, il y a peut-être dix-huit mois, où mon équipe a eu une vraie discussion pour savoir si nous ne faisions pas de la sur-ingénierie.

Nous étions dans une salle de réunion — les tableaux blancs couverts de schémas d'architecture — et l'un de nos ingénieurs seniors a plaidé pour que nous livrions un MVP basé sur un wrapper à un client industriel. « Faisons rentrer du chiffre d'affaires, prouvons le concept, on durcira l'architecture plus tard. » L'argument était raisonnable. Le client était impatient. Le calendrier était serré. Et tous nos concurrents livraient des produits wrapper et signaient des contrats.

Je me souviens du silence quand il a eu fini. Puis Priya — la même ingénieure qui avait attrapé la citation fantôme — a affiché une diapositive qu'elle gardait sous le coude. Elle présentait trois cas réels du trimestre précédent où des systèmes d'IA à base de wrapper avaient produit des sorties qui, si on les avait suivies, auraient violé des exigences réglementaires. Pas des violations hypothétiques. Des vraies, repérées uniquement parce que des humains se trouvaient dans la boucle.

J'ai tranché : nous garderions le cap. Nous avons perdu ce contrat au profit d'un concurrent qui a livré plus vite. Six mois plus tard, le système de ce concurrent a produit une violation de conformité qui a coûté à son client une remédiation à sept chiffres. Le client est venu nous voir.

La vitesse sans exactitude n'est pas un avantage concurrentiel. C'est un passif à retardement.

Je ne raconte pas cette histoire pour avoir l'air visionnaire. Je la raconte parce que la pression pour livrer vite et itérer ensuite est énorme, et que, dans la plupart des contextes logiciels, c'est le bon réflexe. Mais dans les secteurs réglementés — banque, santé, juridique, industrie manufacturière —, « itérer ensuite » veut dire « réparer après la violation ». Et, dans ces domaines, les violations ne s'accompagnent d'aucun délai de grâce.

Pourquoi 2026 est l'année où l'addition arrive

Voici le tableau macro. McKinsey a constaté que, si 88 % des organisations utilisent l'IA, seules 39 % peuvent pointer un impact positif sur les résultats à l'échelle de l'entreprise. Cet écart est sur le point de devenir intenable.

La phase « investir et apprendre » de l'adoption de l'IA est terminée. Les directeurs financiers ne demandent plus « Utilisons-nous l'IA ? ». Ils demandent « Quel est l'impact sur l'EBIT ? ». Et, pour la plupart des organisations, la réponse honnête est : « Nous avons gagné un peu de temps sur des tâches administratives. »

Ce n'est pas suffisant. Gagner du temps sur les e-mails et les présentations, c'est de l'« IA de productivité » — utile mais incrémentale. Ce dont les entreprises ont réellement besoin, c'est d'une « IA opérationnelle » — des systèmes qui éliminent des frictions coûteuses en argent réel dans l'économie physique. Éviter les ruptures de stock. Détecter les violations de conformité avant qu'elles ne surviennent. Réduire les 890 milliards de dollars de coût annuel des retours dans le commerce de détail en proposant un essayage virtuel exact plutôt que des images fantasmées générées par IA, magnifiques mais qui ne reflètent pas la façon dont un tissu tombe réellement sur un corps humain.

L'histoire de Klarna est instructive ici, car leurs indicateurs ressemblaient à du ROI. Coût par transaction en baisse de 40 % ! Mais ils mesuraient la mauvaise chose. Ils ont mesuré le temps gagné et les effectifs réduits. Ils n'ont pas mesuré la confiance érodée ni les clients perdus. Si l'on intègre les coûts de réembauche, les dégâts d'image et la perte de 99 millions de dollars au premier trimestre, les « économies » s'évaporent.

Les entreprises qui gagneront en 2026 seront celles qui mesureront les pertes opérationnelles évitées, et non les heures économisées. Celles qui déploieront une IA capable de simuler 10 000 scénarios de perturbation de la chaîne d'approvisionnement en une nuit et de bâtir des plans de reprise de crise qu'aucune équipe humaine ne pourrait produire en dix ans. Celles dont les systèmes d'IA savent prouver leur raisonnement à un régulateur, et pas seulement produire un paragraphe convaincant.

Et les humains dans tout ça ?

On me renvoie toujours cette objection. « Si l'IA devient aussi bonne, qu'advient-il des gens ? »

Je crois que la réponse est l'inverse de ce que la plupart des gens imaginent. Les organisations qui déploient une IA profonde et architecturalement solide n'ont pas besoin de moins d'humains — elles ont besoin d'humains différents. La pyramide traditionnelle du conseil, avec son immense base d'analystes juniors chargés de la synthèse de données et de la fabrication de présentations, s'effondre. L'IA fait ce travail plus vite et mieux. Mais le besoin de jugement senior, de réflexion stratégique, de supervision éthique et d'empathie humaine authentique ne se contente pas de survivre — il s'intensifie.

Ce qui émerge est ce que le secteur appelle le modèle « Obélisque » : des équipes plus resserrées, à plus forte densité d'experts, où les professionnels en début de carrière sont des « facilitateurs d'IA » qui conçoivent et pilotent les workflows d'IA, où ceux en milieu de carrière sont des « architectes de mission » qui définissent les problèmes qui méritent d'être résolus, et où les dirigeants se concentrent sur le travail profondément humain de construction de la confiance et de navigation dans l'ambiguïté.

L'assistant IA interne de McKinsey, « Lilli », est utilisé par 72 % de ses effectifs et a réduit le temps de recherche de 30 %. Le « Deckster » du BCG automatise la création de présentations. Mais ni l'un ni l'autre cabinet ne rétrécit. Ils se restructurent — en remplaçant le volume par la précision, les heures facturées par les résultats livrés.

L'erreur de Klarna n'a pas été d'utiliser l'IA. Elle a été d'utiliser l'IA comme un remplacement des humains plutôt que comme un amplificateur des capacités humaines. Cette distinction paraît subtile. Elle ne l'est pas. C'est la différence entre 10 millions de dollars d'économies et 99 millions de dollars de pertes.

L'architecture de la confiance

Je veux conclure avec quelque chose qui me trotte dans la tête depuis cette nuit-là, quand Priya a trouvé la citation fantôme.

Nous vivons un moment où des systèmes d'IA peuvent produire des sorties indiscernables du travail d'un expert humain — et qui sont pourtant complètement fausses, avec un aplomb total. Ce n'est pas une limitation temporaire que GPT-6 ou GPT-7 viendra résoudre. C'est une propriété inhérente au fonctionnement des modèles de langage probabilistes. Ils optimisent la plausibilité, pas la vérité. Et dans les domaines où la vérité compte — où une mauvaise réponse signifie une violation de conformité, une erreur de diagnostic, un précédent juridique inventé —, la plausibilité est la chose la plus dangereuse au monde.

La solution n'est pas d'abandonner l'IA. La solution est de construire des systèmes d'IA où la vérité est imposée par l'architecture, et non espérée de façon probabiliste. Où chaque affirmation remonte à une source vérifiée. Où le système, littéralement, ne peut pas générer une sortie qui viole les règles du domaine dans lequel il opère. Où la piste d'audit n'est pas une fonctionnalité — c'est la fondation.

C'est ce que nous construisons chez Veriprajna. Non pas parce que l'IA déterministe est plus facile — elle est considérablement plus difficile. Non pas parce qu'elle fait de meilleures démos — les wrappers font des démos magnifiques. Mais parce que, dans les secteurs qui ne peuvent pas se permettre de deviner, la seule architecture durable est celle qui rend la devinette impossible.

Klarna a appris cette leçon au prix de 700 emplois, d'une baisse de 22 % du CSAT et d'une perte trimestrielle de 99 millions de dollars. La question, pour chaque dirigeant d'entreprise qui lit ces lignes, est simple : voulez-vous l'apprendre par leur histoire, ou par la vôtre ?

L'avenir de l'IA d'entreprise ne consiste pas à rendre les modèles de langage plus intelligents. Il consiste à les rendre redevables — de façon architecturale, prouvable, immuable.

L'ère du wrapper est terminée. Ce qui vient ensuite sera plus difficile à construire, plus lent à livrer, et vaudra chaque mois d'ingénierie supplémentaire. Parce qu'au bout du compte, le seul système d'IA qui vaille la peine d'être déployé est celui sur lequel vous parieriez votre entreprise. Et il ne faut jamais parier son entreprise sur un système incapable de montrer son raisonnement.