Alan, PayFit, Klarna, Doctolib : quatre transformations IA, quatre erreurs de lecture à éviter

Alan ouvre sa codebase aux non-ingénieurs. PayFit structure son adoption autour d'un AI Ops et de 29 champions. Klarna automatise massivement son service client avant de réinvestir dans l'humain. Doctolib fait passer 600 ingénieurs en mode agentic-first. Pris séparément, chacun de ces cas peut servir à défendre presque n'importe quelle thèse sur l'avenir du travail.

C'est précisément le problème.

Ces quatre entreprises ne démontrent pas quatre étapes d'une même révolution IA. Elles montrent quatre réponses organisationnelles à quatre problèmes différents. Le cherry-picking commence lorsque l'on oublie le problème de départ, la nature de la métrique, les garde-fous mis en place et ce que l'entreprise elle-même n'a pas encore démontré.

Ces cas, documentés parmi trente entreprises observées entre janvier et juillet 2026, appellent d'ailleurs deux précautions : le corpus a été sélectionné pour ses signaux organisationnels et ne prétend pas être représentatif ; une même entreprise peut relever de plusieurs modèles d'organisation.

En bref

• •Alan ne prouve pas que les ingénieurs deviennent inutiles : son ouverture du build aux PM et designers repose justement sur davantage de règles, de pairing et de review.
• •PayFit ne prouve pas qu'il suffit de nommer des champions IA : son dispositif fonctionne comme une articulation entre orchestration centrale, sponsors et responsabilité distribuée.
• •Klarna ne prouve ni que « l'IA remplace 700 personnes », ni que « l'IA a échoué » : le cas montre surtout qu'un gain d'efficacité peut coexister avec une correction du modèle lorsque la qualité et l'accès à l'humain deviennent insuffisants.
• •Doctolib ne prouve pas qu'un passage à 100 % d'usage agentique produit automatiquement un gain de productivité : l'entreprise dit elle-même qu'il est encore trop tôt pour le mesurer.
• •La leçon commune est moins spectaculaire : la transformation devient organisationnelle lorsque l'entreprise redéfinit qui peut produire, qui doit vérifier, qui décide et qui assume le résultat.

Le problème n'est pas le manque de cas, c'est la façon dont nous les lisons

Les cas d'entreprise sont devenus la matière première du discours sur l'IA.

Une entreprise annonce un gel des embauches : l'IA permettrait de croître sans recruter. Une autre réduit la taille d'une équipe : les organisations deviendraient mécaniquement plus petites. Une troisième ouvre le code aux métiers : les frontières professionnelles seraient en train de disparaître. Une quatrième affiche 100 % d'adoption : elle aurait trouvé la recette de la productivité.

Chaque raccourci contient parfois une part de vérité. Aucun n'est une démonstration suffisante.

Une métrique d'adoption ne mesure pas nécessairement la productivité. Une métrique de production ne mesure pas nécessairement la qualité. Une baisse d'effectifs ne permet pas d'isoler la causalité de l'IA. Une nouvelle organisation ne démontre pas qu'elle serait meilleure dans un autre contexte.

C'est pourquoi la question utile n'est pas « quelle entreprise faut-il imiter ? ». Elle est : « quel problème cette entreprise cherchait-elle à résoudre, quel contrat de travail humain-IA a-t-elle mis en place, et quelle partie du résultat est réellement documentée ? »

Alan : distribuer la capacité de construire ne supprime pas le besoin d'expertise

La transformation d'Alan est probablement l'une des plus faciles à surinterpréter.

Avec Everyone Can Build, l'entreprise veut permettre à des designers, PM et autres non-ingénieurs de modifier directement le produit. Dans un retour publié fin 2025, Alan indiquait que 283 pull requests provenant de non-ingénieurs avaient été mises en production après deux trimestres. L'entreprise décrit un environnement standardisé, des règles communes pour les agents de code et un accompagnement destiné à rendre la contribution accessible.

Le retour d'expérience recueilli par TPC va plus loin : périmètre initial limité, engineering buddy, assessment de complexité, batches de review et décision de merge conservée côté engineering. Le même retour précise également qu'Alan ne dispose pas encore d'une mesure robuste permettant d'attribuer un ROI global à cette transformation.

L'erreur de lecture : « Si un PM peut coder, il faut moins d'ingénieurs »

C'est possible dans certaines configurations. Mais ce n'est pas ce que le cas Alan démontre.

Ce qu'il montre réellement est la suppression d'un handoff : une petite modification n'a plus nécessairement besoin de passer du PM au designer puis à l'ingénieur avant d'exister dans le produit.

La distinction est importante. Le métier d'ingénieur ne disparaît pas du système : une partie de sa valeur se déplace de la production exclusive vers l'environnement qui rend la production distribuée sûre. Review, architecture, developer experience, tests et règles de contribution deviennent les conditions de l'ouverture.

Alan avait d'ailleurs déjà, avant cette vague IA, une culture de responsabilité distribuée et de documentation écrite. Son organisation produit repose historiquement sur des équipes transverses et une forte autonomie. L'IA arrive donc sur un terrain particulièrement favorable ; elle ne crée pas cette culture à partir de zéro.

Ce que cela prouve : certaines barrières entre Product, Design et Engineering peuvent être abaissées lorsque le système de review et l'environnement technique le permettent.

Ce que cela ne prouve pas : que chaque entreprise peut ouvrir sa codebase de la même manière, que la profondeur d'expertise devient moins nécessaire, ou que le nombre de contributions constitue à lui seul une mesure de valeur.

La véritable transformation d'Alan n'est donc peut-être pas « tout le monde devient développeur ». Elle est plutôt : plus de personnes peuvent produire, tandis que l'expertise se déplace vers la création et la protection du cadre dans lequel cette production devient possible.

PayFit : institutionnaliser l'IA sans fabriquer un goulot central

PayFit raconte une autre trajectoire.

Le rôle de Senior AI Ops a été conçu pour porter transversalement l'adoption, la gouvernance, le support aux équipes, le suivi des outils et l'animation d'une communauté interne. La fiche de poste publiée par PayFit le positionnait dans Product Ops, en interaction avec Product, Engineering et les fonctions opérationnelles.

Le retour terrain recueilli par TPC documente ensuite 29 champions répartis dans neuf grands départements, avec un AI Ops pour plus de 700 collaborateurs. Les sponsors donnent l'ambition et les moyens ; les champions identifient et diffusent les usages ; les builders réalisent et mesurent les cas d'usage. Un champion sans temps alloué produit peu d'effet.

L'erreur de lecture : « Il suffit de créer un AI Ops et un réseau de champions »

Le nombre de champions est une donnée d'organisation, pas une métrique d'impact.

Un réseau de 29 personnes peut être extrêmement actif ou devenir une collection d'ambassadeurs sans mandat. PayFit lui-même le traite comme une infrastructure d'adoption : le sponsor, le temps disponible, les usages mis en production et la mesure des résultats comptent davantage que le nombre de volontaires.

C'est là que le cas devient intéressant. Il ne tranche pas vraiment entre centralisation et décentralisation. Il combine les deux.

Le centre ne cherche pas à produire tous les cas d'usage. Il fournit méthode, cohérence, gouvernance et diffusion. Les métiers conservent la connaissance du problème et reprennent progressivement la responsabilité des usages.

Le mouvement va désormais au-delà de l'adoption interne. En juillet 2026, PayFit a annoncé avoir atteint la rentabilité et faire évoluer son positionnement d'éditeur vers un service paie et RH augmenté par l'IA, associant sa plateforme, PayFit AI et environ 200 experts paie. L'entreprise précise que les clients gardent des validations aux étapes clés et que les experts humains interviennent lorsque nécessaire. Ces éléments viennent d'une communication de PayFit : ils documentent une orientation stratégique, pas son impact économique futur.

Ce que cela prouve : une entreprise peut passer de l'expérimentation dispersée à un dispositif explicite d'adoption sans nécessairement construire un gros département IA central.

Ce que cela ne prouve pas : que l'AI Ops est le modèle optimal partout, que 29 champions produisent un ROI mesurable, ou que ce dispositif fonctionnerait sans sponsors ayant réellement la capacité de libérer du temps.

La leçon est moins « créez un poste AI Ops » que : « donnez un propriétaire aux problèmes transverses que les équipes locales ne peuvent pas résoudre seules, puis renvoyez la propriété des usages au plus près du métier. »

Klarna : le cas qui permet de raconter deux histoires opposées, toutes deux trop simples

Klarna est probablement le meilleur test de résistance à notre discipline intellectuelle.

En février 2024, l'entreprise annonçait que son assistant IA avait traité 2,3 millions de conversations en un mois, soit les deux tiers de ses chats de service client, pour une charge présentée comme équivalente au travail de 700 agents à temps plein. Klarna déclarait également un temps de résolution passé de 11 à moins de 2 minutes, une baisse de 25 % des demandes répétées et une satisfaction comparable à celle des agents humains. Toutes ces données étaient communiquées directement par Klarna et doivent donc être lues comme telles.

Un an plus tard, la société continuait de mettre en avant d'importants gains d'efficacité. Dans ses résultats du premier trimestre 2025, Klarna indiquait avoir réduit son effectif d'environ 40 % depuis 2022, augmenté fortement son revenu par salarié et diminué son coût de service par transaction. Là encore, ce sont des données et attributions publiées par l'entreprise.

Puis le discours a changé.

En mai 2025, Sebastian Siemiatkowski reconnaissait que le coût était devenu un critère trop dominant dans l'organisation du support et que le résultat pouvait être une qualité inférieure. Klarna a alors commencé à développer un dispositif permettant de renforcer l'accès à des agents humains, avec l'ambition explicite qu'un client puisse toujours parler à une personne s'il le souhaite.

Première erreur de lecture : « Klarna a remplacé 700 salariés par l'IA »

Ce n'est pas ce que disait l'annonce originale. Klarna parlait d'un équivalent de travail de 700 ETP, pas de 700 licenciements directement et causalement attribués à l'assistant. La réduction d'effectif s'inscrivait dans un gel des recrutements, de l'attrition et une restructuration plus large de l'entreprise.

Deuxième erreur de lecture : « Klarna a essayé l'IA, cela a échoué, elle réembauche des humains »

Cette lecture est tout aussi fragile. L'entreprise n'a pas abandonné son IA. Au moment même où elle renforçait la place du support humain, un porte-parole de Klarna précisait que ce dispositif devait compléter l'IA plutôt que signaler une marche arrière générale.

Le cas documente donc quelque chose de plus utile qu'un succès ou un échec : une frontière d'automatisation a été déplacée après confrontation avec une autre variable que le coût, la qualité perçue et la possibilité d'obtenir une interaction humaine.

C'est précisément ce que les tableaux de bord d'automatisation peuvent masquer. Une organisation peut améliorer le temps de réponse, réduire les recontacts et diminuer le coût moyen tout en découvrant que certaines interactions ont une valeur relationnelle ou une complexité qui justifie un autre traitement.

Le choix organisationnel n'est alors plus « humain ou IA ». Il devient : quelles demandes peuvent être automatisées, lesquelles doivent être escaladées, quelle autorité possède l'humain sur les exceptions et quels indicateurs empêchent une optimisation locale du coût de dégrader l'expérience globale ?

Doctolib : 100 % d'adoption ne signifie pas 100 % de productivité prouvée

Doctolib fournit le cas le plus spectaculaire côté engineering, mais aussi l'un de ceux où la prudence méthodologique est la plus instructive.

Depuis janvier 2026, les 600 ingénieurs de développement utilisent des agents IA dans un fonctionnement qualifié d'agentic-first. Certains font fonctionner jusqu'à huit agents en parallèle. L'organisation a parallèlement renforcé les spécifications, développé une plateforme interne, mis en place des services communs et expérimenté des agents sur le traitement de tickets, certains changements techniques et la review.

L'erreur de lecture : « 600 ingénieurs à 100 % avec des agents égale gain massif de productivité »

Doctolib ne le dit pas. Au contraire, Julien Tanay, Staff SRE, expliquait au printemps 2026 qu'il était encore trop tôt pour conclure sur l'impact de la transformation. Les équipes codent plus vite, mais passent également davantage de temps en review. L'entreprise continuait à suivre qualité et durée des opérations avant de déterminer si l'agentic-first permettait effectivement de mettre davantage de fonctionnalités en production.

C'est un point majeur : l'adoption est une variable d'entrée. La productivité nette est une variable de sortie.

Entre les deux se trouvent les specs, la qualité du contexte, le volume généré, la review, les tests, les erreurs, le rework, la merge queue et finalement la valeur réellement livrée.

C'est également pourquoi le cas Doctolib est plus intéressant comme transformation du système de production que comme benchmark de productivité. Lorsque des centaines d'agents doivent comprendre une codebase, l'entreprise doit améliorer sa documentation. Lorsque la production accélère, les critères d'acceptation et la review prennent davantage d'importance. Lorsque des tâches deviennent automatisables, il faut distinguer celles qui sont suffisamment répétables de celles qui requièrent encore un jugement humain.

Le parallèle existe dans d'autres métiers intellectuels : plus l'IA accélère la production dans le conseil, plus la responsabilité tend à remonter vers celui qui vérifie et signe. Cette analogie aide à penser le cas Doctolib, mais elle ne constitue évidemment pas une preuve supplémentaire sur l'engineering.

Ce que Doctolib prouve : une organisation de plusieurs centaines d'ingénieurs peut généraliser un mode de développement profondément agentique et adapter ses infrastructures et ses pratiques en conséquence.

Ce qu'il ne prouve pas encore : le niveau de gain de productivité, la réduction possible de la taille des équipes, ni la soutenabilité à long terme de ces nouveaux workflows.

Ces quatre entreprises n'illustrent pas quatre niveaux de maturité

C'est probablement la conclusion la plus importante de la comparaison.

Alan, PayFit, Klarna et Doctolib ne se situent pas sur une ligne allant de « peu IA » à « très IA ». Ils ont déplacé des frontières différentes.

Chez Alan, la frontière bouge entre ceux qui peuvent produire et ceux qui contrôlent la production. Chez PayFit, elle bouge entre responsabilité centrale et appropriation locale. Chez Klarna, elle bouge entre traitement automatisé du volume et intervention humaine sur les interactions où la qualité relationnelle compte davantage. Chez Doctolib, elle bouge entre production du code, spécification, orchestration et review.

Même les catégories utilisées dans cet article doivent donc être maniées avec prudence : Alan, PayFit et Doctolib relèvent tous de l'adoption distribuée, mais PayFit se rattache également au modèle « humain sur les exceptions » et Doctolib au développement agentique. Les modèles se superposent parce qu'ils répondent à des problèmes différents.

La transformation IA ressemble moins au choix d'un organigramme cible qu'à la renégociation d'une série de contrats de travail : qui produit, qui contrôle, qui possède le contexte, qui peut décider et qui porte la responsabilité finale.

Ce que ces quatre cas ne permettent surtout pas d'affirmer

Ils ne démontrent pas que les organisations vont mécaniquement réduire leurs effectifs. Ils ne démontrent pas qu'une adoption élevée provoque une productivité élevée. Ils ne démontrent pas que les rôles spécialistes disparaissent au profit de généralistes. Ils ne démontrent pas non plus que toutes les transformations profondes exigent de modifier l'organisation.

Deux contre-exemples du même corpus sont particulièrement utiles.

Lucca a intégré des fonctionnalités IA tout en conservant ses équipes produit de six à huit personnes et une doctrine dans laquelle l'IA propose tandis que le RH, le recruteur ou le manager reste décisionnaire. Aucune donnée publique ne permet d'attribuer à l'IA un gain de productivité ou une réduction d'effectif.

Pennylane, de son côté, continue de recruter fortement, embarque notamment d'anciens experts-comptables dans ses fonctions Product et ne présente pas de refonte organisationnelle générale liée à l'IA dans les éléments documentés.

Ces contre-exemples ne réfutent pas les quatre cas précédents. Ils réfutent l'idée plus générale selon laquelle utiliser intensément l'IA obligerait nécessairement à adopter une organisation plus petite, plus plate ou plus agentique.

La lecture DRYVE : la bonne unité d'analyse n'est pas l'entreprise, mais la boucle de travail

Le signal organisationnel le plus robuste n'est pas qu'un modèle précis soit en train de gagner. C'est que les entreprises les plus avancées cessent progressivement de raisonner en termes de « tâches confiées à l'IA » pour redessiner des boucles complètes de production, de contrôle et de décision.

Cette distinction change beaucoup de choses.

Acheter un copilote modifie une tâche. Permettre à un designer de pousser une PR modifie un workflow. Créer des prompt owners et des champions modifie la responsabilité. Faire d'un agent le premier reviewer modifie le contrôle qualité. Réserver certains cas à l'humain modifie la division du travail. Redéfinir ce qui est réversible ou irréversible modifie le droit de décision.

Ce sont ces déplacements-là qu'un dirigeant devrait chercher lorsqu'il étudie un cas externe. Pas le nombre de licences. Pas le nombre d'agents. Pas même le pourcentage de code ou de tickets traité par l'IA pris isolément.

Le vrai indicateur d'une transformation est que le travail humain restant n'est plus organisé de la même manière qu'avant.

Ce que cela pose concrètement aux dirigeants

Le premier enjeu est de distinguer diffusion et transformation. Une organisation peut compter des centaines d'utilisateurs actifs sans avoir modifié ses handoffs, ses responsabilités ou ses décisions. Inversement, une automatisation ciblée peut transformer profondément une fonction sans que toute l'entreprise utilise l'IA.

Le deuxième est de ne jamais piloter un dispositif sur une seule métrique. Le volume automatisé doit être rapproché de la qualité, du taux d'exception, du rework et de la satisfaction. Le nombre de PR générées doit être rapproché du temps de review et des défauts. Le nombre de champions doit être rapproché des usages passés en production et de leurs résultats.

Le troisième est de regarder où apparaît le nouveau goulot. Alan fait remonter le sujet vers la review. PayFit vers l'orchestration et la capitalisation. Klarna vers la qualité des interactions complexes. Doctolib vers les specs, le contexte et la revue. L'IA ne supprime pas nécessairement la contrainte : elle la déplace. C'est l'un des enseignements transversaux les plus solides du corpus.

Enfin, il faut accepter qu'un bon dispositif puisse être corrigé. Klarna est intéressant justement parce que l'organisation n'est pas restée prisonnière de son premier récit. Dans un domaine où les capacités techniques évoluent très vite, la capacité à remettre une frontière humain-IA en question est probablement plus utile qu'une doctrine « AI-first » intangible.

Grille anti-cherry-picking : dix questions avant de citer un cas d'entreprise

• •Quel est exactement le changement documenté ? Outil, tâche, workflow, rôle, droit de décision, structure, effectif ou business model ?
• •Quelle était la situation de départ ? Sans baseline, un résultat absolu est difficile à interpréter.
• •Quelle métrique est utilisée ? Adoption, volume produit, délai, qualité, coût, revenu, satisfaction ou effectif ?
• •Qui fournit la donnée ? Entreprise elle-même, étude indépendante, témoignage terrain, presse ou source réglementaire ?
• •S'agit-il d'un résultat observé ou d'un objectif annoncé ?
• •La causalité IA est-elle démontrée ? Quels autres facteurs ont changé en même temps ?
• •Quel contrôle humain reste dans la boucle ? Qui vérifie, décide et assume lorsque l'IA se trompe ?
• •Quel nouveau goulot est apparu ? Review, specs, exceptions, données, adoption, sécurité ou décision ?
• •Existe-t-il un contre-signal ? Réembauche, rework, maintien des équipes, hausse des recrutements ou absence de ROI mesuré ?
• •Quelles conditions rendent le cas transposable chez nous ? Culture, maturité technique, réglementation, qualité des données, profils disponibles et capacité managériale ?

Si plusieurs réponses manquent, le cas reste intéressant. Mais il doit être utilisé comme hypothèse, pas comme preuve.

La conviction

Il n'existe pas de « cas IA » que l'on puisse copier sans perdre l'essentiel.

Alan n'est pas une preuve qu'il faut faire coder tous les métiers. PayFit n'est pas une preuve qu'il faut recruter un AI Ops. Klarna n'est ni la preuve que l'IA remplace le support, ni celle qu'elle ne le peut pas. Doctolib n'est pas la preuve que 100 % d'adoption produisent automatiquement une organisation plus productive.

Ces entreprises sont utiles parce qu'elles permettent d'étudier des décisions organisationnelles concrètes sous contraintes.

La question à importer n'est donc jamais « comment faire comme eux ? ». Elle est : « quel problème ont-ils résolu, quel prix organisationnel ont-ils payé et avons-nous chez nous les mêmes conditions pour que ce choix ait du sens ? »