Organisation et IA : il n'existe pas de modèle idéal — seulement le bon diagnostic

Déployer l'IA est, comparativement, la partie facile du problème. La question qui engage vraiment une organisation est différente : où placer les compétences, qui a le droit d'agir, qui contrôle la qualité, et ce qui doit réellement changer dans la structure.

En observant un certain nombre d’entreprises engagées dans leur transformation IA, six modèles organisationnels se distinguent : adoption distribuée, centre d'excellence centralisé, équipe produit hybride, humain sur les exceptions, développement agentique, organisation AI-native. Mais l'enseignement le plus utile n'est pas cette liste — c'est qu'aucun de ces six modèles ne constitue une organisation cible universelle. Les cas retenus l'ont été pour la clarté de leurs signaux organisationnels, pas pour représenter le marché dans son ensemble.

La question qu'un dirigeant devrait se poser n'est donc pas « quel modèle les entreprises les plus avancées ont-elles adopté ? », mais : quel problème organisationnel cherchons-nous à résoudre, et quel operating model le résout sans créer un nouveau goulot ou un nouveau risque ?

C'est la thèse de cet article. Les six modèles ne sont ni des niveaux de maturité, ni des étapes d'une même trajectoire : ce sont six réponses à des contraintes différentes. Et une même entreprise peut, légitimement, en combiner plusieurs à la fois.

En bref

• •Il n'existe pas de modèle organisationnel supérieur dans l'absolu. Le bon choix dépend du goulot à traiter : diffusion des usages, rareté des compétences, vitesse produit, volume opérationnel, capacité de développement, ou construction AI-native dès l'origine.
• •Centraliser ou décentraliser n'est presque jamais un choix binaire. Les cas les plus solides combinent un noyau central resserré — plateforme, gouvernance, expertise — et des responsabilités distribuées dans les métiers.
• •Les organisations les plus spectaculaires ne sont pas les plus transposables. Anthropic, OpenAI, Dust ou Mistral sont des références utiles, pas des modèles applicables tels quels à une scale-up historique.
• •Le vrai risque n'est pas de choisir le mauvais modèle : c'est d'en choisir un parce qu'il paraît moderne, et de découvrir qu'il déplace simplement le problème ailleurs — du développement vers la review, du support vers les exceptions, des métiers vers un centre d'excellence saturé.
• •Avant toute réorganisation globale, le modèle peut presque toujours être testé sur un flux, un pod ou une fonction, pendant 30 à 60 jours.

1. Le vrai point de départ : quel goulot voulons-nous déplacer ?

La tentation est forte de transformer l'organisation dès que l'usage de l'IA décolle : créer une équipe IA, nommer des champions, fusionner des rôles, automatiser un service, demander aux développeurs de devenir « agentic-first ». Les cas observés invitent à plus de prudence.

Cinq phénomènes transversaux reviennent régulièrement : une partie du travail se déplace vers la supervision et le traitement des exceptions ; certains rôles s'hybrident ; dans quelques équipes techniques, le goulot glisse vers la décision et les evals ; un noyau central s'associe fréquemment à des relais distribués ; et — signal moins commenté mais tout aussi réel — plusieurs entreprises pourtant engagées dans l'IA n'ont procédé à aucune refonte organisationnelle.

Ce dernier point mérite l'attention d'un dirigeant. Lucca, par exemple, conserve ses équipes de 6 à 8 personnes organisées par application et maintient explicitement la décision du côté des RH et des managers. Pennylane a intégré l'IA à son produit et mobilise d'anciens experts-comptables dans des rôles produit, sans qu'aucune refonte organisationnelle attribuable à l'IA ne soit documentée.

Adopter davantage d'IA et réorganiser l'entreprise sont deux décisions distinctes. La seconde devient pertinente lorsqu'un problème structurel apparaît : initiatives dupliquées, compétence rare saturée, review devenue trop lente, croissance des volumes impossible à absorber, rôles trop cloisonnés, responsabilité floue. C'est à partir de ce problème — et non d'une tendance de marché — qu'il faut choisir un modèle.

Les six modèles en une grille

Cette grille reprend les six archétypes observés dans le corpus ; les catégories se chevauchent, et un même cas peut relever de plusieurs modèles à la fois. Elle doit être utilisée comme un outil de raisonnement — pas comme un benchmark normatif.

2. Adoption distribuée — rapprocher l'IA du travail réel

Dans une organisation distribuée, les métiers ne transmettent pas leurs besoins à une « équipe IA » chargée de tout construire : les équipes expérimentent, adaptent, et parfois construisent elles-mêmes leurs usages. Encore faut-il distinguer adoption distribuée et laisser-faire.

Le cas PayFit est instructif. L'entreprise a mis en place un AI Ops transverse, des prompt owners et un réseau d'une trentaine de champions, pour environ 600 utilisateurs actifs de sa plateforme IA interne selon un retour d'expérience publié en 2026. Les champions y sont soutenus par des sponsors de département, chargés de libérer du temps et de lever les obstacles : la diffusion reste locale, mais elle est organisée.

Ce que cela montre : un petit dispositif transverse peut permettre aux usages de rester proches du terrain sans concentrer toute la transformation dans une équipe centrale.

Ce que cela ne montre pas : ni le nombre de champions ni le nombre d'utilisateurs ne prouvent, à eux seuls, un impact économique. L'adoption y est le plus souvent mesurée par des connexions ou des usages — beaucoup plus rarement par des résultats isolables.

Quand ce modèle fonctionne le mieux

Lorsque les équipes disposent déjà d'une culture numérique suffisante pour expérimenter, qu'un socle d'outils commun existe, et que les risques restent contrôlables localement. Il suppose au minimum :

• •un sponsor exécutif ;
• •une responsabilité explicite sur la plateforme et les standards ;
• •du temps réellement alloué aux relais locaux ;
• •un mécanisme de capitalisation des usages ;
• •des métriques qui dépassent la simple utilisation de l'outil.

Le piège : construire une communauté de volontaires très active, mais sans pouvoir réel de modifier les workflows, les objectifs ou les priorités.

3. Centre d'excellence centralisé — concentrer ce qui ne peut pas encore être distribué

La centralisation répond au problème inverse : lorsque les compétences sont rares, la conformité élevée, ou l'infrastructure encore instable, demander à chaque équipe de devenir autonome peut multiplier les choix techniques, les coûts et les risques.

Qonto illustre une forme de centralisation de la stratégie : la création d'un rôle de Head of AI Products pilotant plusieurs produits IA, tandis que les compétences de ML engineering ont été rapprochées du software engineering.

Ce point mérite d'être relevé : centraliser l'IA ne signifie pas nécessairement créer une grande équipe de machine learning. Ce qui peut être centralisé, c'est plutôt : l'architecture, les standards de fiabilité, la gouvernance, les evals, les fournisseurs, les données communes, et certains produits ou composants transverses. Les métiers, eux, conservent la responsabilité du problème à résoudre.

Le principal avantage : éviter que vingt équipes résolvent vingt fois les mêmes problèmes de sécurité, de plateforme ou d'évaluation.

Le principal danger : transformer une compétence rare en file d'attente. Le centre d'excellence devient alors un service interne où toutes les demandes remontent, où les métiers attendent, et où les experts centraux perdent progressivement le contexte nécessaire pour arbitrer correctement.

Un bon centre d'excellence a donc besoin d'une stratégie de sortie partielle : ce qu'il veut continuer à posséder dans deux ans, et ce qu'il veut rendre progressivement autonome dans les équipes.

4. Équipe produit hybride — réduire les handoffs, pas les expertises

L'un des signaux les plus commentés concerne la porosité croissante entre Product, Design, Data et Engineering.

Instagram en offre une illustration nette. Adam Mosseri a décrit, en juillet 2026, une évolution de l'équipe produit type vers des pods plus réduits — quatre à six ingénieurs généralistes — complétés par un « product staff » mêlant des dimensions historiquement portées séparément par le produit, le design, la data et la recherche. Cette évolution est présentée comme un mouvement en cours, pas comme un nouveau standard établi.

Ce cas intéresse moins par le chiffre que par la logique qu'il révèle. Lorsque l'IA réduit le coût d'un prototype, d'une analyse ou d'un premier écran, les dépendances entre métiers se desserrent : un PM va plus loin dans le prototypage, un designer touche au produit réel, un ingénieur explore plus directement une question produit. Les handoffs diminuent. Cela ne signifie pas que les expertises deviennent interchangeables.

Le risque de mauvaise lecture

Confondre polyvalence accrue et disparition de la spécialisation. Une petite équipe généraliste fonctionne mieux lorsque :

• •le problème reste circonscrit ;
• •la qualité peut être revue ;
• •des spécialistes restent mobilisables à la demande ;
• •les personnes ont réellement acquis plusieurs compétences.

Elle fonctionne beaucoup moins bien si l'on se contente de supprimer le designer, le data analyst ou le PM en supposant que l'IA absorbera la profondeur de leur métier.

Conclusion plus nuancée : les rôles ne disparaissent pas nécessairement — leurs frontières deviennent plus poreuses, et leur combinaison évolue.

5. Humain sur les exceptions — puissant, à condition de concevoir aussi le travail qui reste

C'est probablement le modèle le plus immédiatement applicable aux opérations. Le principe : l'IA absorbe les cas standards, l'humain traite les situations incertaines ou sensibles.

Roundtable en fournit une illustration lisible : sur un flux de contrôle de 1 000 SPV, l'automatisation sert à isoler une quinzaine à une vingtaine de dossiers problématiques que l'humain doit réellement examiner — un témoignage, non une étude indépendante de performance. Le potentiel est réel pour le support, les opérations financières, la conformité, ou certains traitements administratifs.

Mais ce modèle a un angle mort : ce qui reste à l'humain n'est pas un échantillon représentatif du travail précédent. Ce sont précisément les clients mécontents, les dossiers ambigus, les erreurs, les situations inhabituelles, les décisions difficiles, les cas engageant une responsabilité.

Klarna offre ici un contre-exemple utile aux lectures trop rapides. Après avoir fortement automatisé son support et réduit ses effectifs, l'entreprise a réintroduit davantage de capacité humaine, afin de garantir l'accès à une personne sur les situations où la qualité de l'interaction comptait le plus. L'IA reste centrale : il s'agit d'une correction du périmètre d'automatisation, pas d'un abandon — une évolution confirmée par plusieurs comptes rendus publics.

La question souvent oubliée n'est pas seulement « quel pourcentage pouvons-nous automatiser ? », mais « quel travail produisons-nous pour les personnes qui resteront ? ». Si les humains héritent en continu des 5 % de cas les plus difficiles, l'entreprise doit repenser les compétences requises, les effectifs nécessaires aux pics, les temps de récupération, le pouvoir de décision, les mécanismes d'escalade, et la boucle par laquelle les exceptions viennent améliorer le système. À défaut, l'automatisation peut réduire le volume humain tout en augmentant son intensité.

Les métriques indispensables : le taux d'automatisation seul ne suffit pas. Il faut suivre au minimum le volume, le taux d'exception, l'erreur, le rework, le délai, la qualité ou la satisfaction, et le coût.

6. Développement agentique — quand produire davantage ne suffit plus

L'organisation du développement change de nature lorsqu'un agent ne se contente plus de compléter quelques lignes, mais prend en charge une tâche entière : produire des pull requests, écrire des tests, lancer plusieurs travaux en parallèle.

Doctolib en offre un exemple particulièrement documenté. Après une phase d'expérimentation en 2025, l'entreprise a généralisé début 2026 une approche « agentic-first » à ses 600 développeurs ; certains ingénieurs font travailler jusqu'à huit agents en parallèle, selon les responsables interrogés. Le changement s'accompagne d'un investissement soutenu dans les spécifications et le contexte fourni aux agents — des éléments confirmés publiquement lors de Devoxx en avril 2026.

Le chiffre le plus important n'est pas « 600 ». C'est le déplacement du goulot. Quand produire un premier jet de code devient beaucoup plus rapide, les contraintes remontent vers la qualité de la spécification, les critères d'acceptation, les tests et les evals, l'architecture, la review, la merge queue, et finalement les décisions produit. Un déplacement retrouvé chez Anthropic, Stripe, Dust ou Qonto — mais qui semble concerner surtout des organisations à forte culture d'ingénierie, et ne peut pas être généralisé en l'état.

Le contre-exemple à garder en tête : plus de code n'est pas nécessairement plus de valeur. Si l'équipe multiplie les pull requests sans que la review, les tests ou les arbitrages ne suivent, l'agent accélère surtout la création d'une file d'attente.

La question organisationnelle devient alors : quelle capacité de décision et de contrôle devons-nous construire pour absorber cette nouvelle capacité de production ? C'est une transformation du système de travail — pas un changement d'outil.

7. Organisation AI-native — une référence, rarement une cible de réorganisation

Anthropic, OpenAI ou Mistral exercent une fascination compréhensible : leurs organisations semblent parfois préfigurer ce que deviendraient toutes les entreprises, une fois l'IA suffisamment avancée. Cette conclusion est trop forte. Ces entreprises sont nées autour de l'IA — elles n'ont pas eu à transformer une organisation historique pour l'intégrer.

Dust illustre bien l'intérêt, et la limite, de ces références. Son cofondateur Stanislas Polu déclarait en mars 2026 que la part de code produite avec des agents était passée d'environ 20 % à près de 70 % en quelques semaines, tout en insistant sur la nécessité de conserver une forte technicité et une capacité d'orchestration pour éviter de dégrader la codebase.

Ce cas montre jusqu'où certains modes de travail peuvent aller. Il ne démontre pas que 70 % constitue un objectif pertinent pour une entreprise quelconque, qu'une équipe produit historique peut supprimer ses fonctions existantes, que le même modèle fonctionne avec une architecture legacy ou des contraintes réglementaires lourdes, ou qu'une entreprise mature peut reproduire la densité de compétences d'une startup IA.

Les ratios spectaculaires des entreprises AI-native doivent être utilisés comme des questions adressées à l'organisation, pas comme des benchmarks. « Que devrions-nous changer si le coût de production d'un prototype était divisé par plusieurs ? » est une question utile. « Pourquoi n'avons-nous pas le même ratio d'ingénieurs que Dust ou Anthropic ? » l'est beaucoup moins.

8. Ce que montrent réellement les cas — et ce qu'ils ne montrent pas

Ce que les données permettent raisonnablement d'affirmer

Plusieurs entreprises ont modifié la division du travail — collaborateurs devenus superviseurs, rôles rendus plus polyvalents, création de fonctions d'interface (AI Ops, champions, ML Analysts). Plusieurs cas combinent une infrastructure ou une gouvernance centrale avec des usages fortement distribués : le choix réel est donc moins « central ou local » que « qu'est-ce qui doit être central, et qu'est-ce qui doit rester local ? ». Des organisations automatisent une part significative de leurs flux opérationnels et concentrent l'intervention humaine sur les exceptions. Dans certaines équipes de développement avancées, les spécifications, la review et les evals deviennent des contraintes plus visibles à mesure que les agents produisent davantage. Et plusieurs entreprises adoptent l'IA sans modifier profondément leur structure existante.

Ce que les données ne permettent pas d'affirmer

Elles ne démontrent pas qu'un modèle produit systématiquement une meilleure croissance ou une meilleure rentabilité, qu'une organisation plus petite est nécessairement plus performante, ou une réduction généralisée des effectifs attribuable à l'IA. Elles ne permettent pas d'extrapoler les ratios d'une entreprise AI-native à une organisation historique, ni de transformer des résultats déclarés ou des témoignages en causalité démontrée.

Cette prudence rejoint une idée développée dans un autre secteur, celui du conseil : l'augmentation de la capacité de production déplace la valeur vers l'orchestration, le jugement, le contrôle et la responsabilité. La transposition est utile pour les organisations Product et Ops, mais elle reste une déduction.

9. Mon interprétation— choisir par le goulot, pas par le niveau de sophistication

Trois convictions se dégagent de ces cas.

1. Les six modèles ne forment pas une échelle de maturité

Passer d'un centre d'excellence à un modèle distribué n'est pas nécessairement « progresser ». Une entreprise réglementée peut avoir durablement intérêt à conserver une gouvernance centralisée. Une startup de 40 personnes n'a probablement aucun intérêt à construire un centre d'excellence de grande taille. Une équipe produit peut s'hybrider sans que le support adopte le même modèle. Le modèle dépend du travail concerné.

2. L'organisation la plus robuste sera souvent composite

Une scale-up peut parfaitement combiner une plateforme et une gouvernance centrales, des champions et des builders distribués, une partie du support organisée autour de l'humain sur les exceptions, quelques équipes techniques en développement agentique, et des pods produit plus hybrides. Ce n'est pas une incohérence : c'est probablement plus réaliste que de déclarer toute l'entreprise « AI-first » et d'imposer la même organisation à la finance, au support, au produit et à l'engineering.

3. Le bon modèle déplace un goulot. Le mauvais ne fait que le cacher.

Une équipe centrale peut résoudre un problème de gouvernance et créer un problème de délai. Une automatisation peut résoudre un problème de volume et créer un problème d'exceptions. Une équipe hybride peut résoudre un problème de handoffs et créer un problème de profondeur d'expertise. Le développement agentique peut résoudre un problème de capacité de production et créer un problème de review.

La question à poser avant toute réorganisation n'est donc pas « quel modèle choisir ? », mais : quel nouveau goulot sommes-nous prêts à gérer ?

10. Cinq décisions à prendre avant de toucher à l'organigramme

Décision 1 — Définir précisément le problème

« Accélérer avec l'IA » n'est pas un problème organisationnel. En revanche, le sont : des initiatives dupliquées, des experts IA saturés, un support qui croît au même rythme que les clients, une review qui empêche d'absorber les productions des agents, ou des équipes produit qui passent trop de temps à attendre les autres fonctions.

Décision 2 — Séparer ce qui doit être mutualisé de ce qui nécessite du contexte métier

La plateforme, la sécurité, les fournisseurs ou certains standards peuvent être centraux. Les décisions métier, les critères de qualité et l'identification des usages gagnent souvent à rester proches du terrain. Tracer cette frontière est une décision d'organisation à part entière.

Décision 3 — Écrire les droits de décision

Pour chaque workflow utilisant un agent : qui demande ? qui spécifie ? qui produit ? qui vérifie ? qui peut bloquer ? qui décide ? qui assume ? Plus l'autonomie technique augmente, plus cette répartition doit être explicite.

Décision 4 — Mesurer le résultat, pas seulement l'adoption

« 80 % des salariés utilisent l'IA » ne dit presque rien de la qualité de l'organisation. La mesure pertinente dépend du workflow : délai, volume, qualité, erreur, rework, coût, satisfaction, temps humain, vitesse de décision.

Décision 5 — Tester l'operating model avant de réorganiser l'entreprise

L'une des forces de ces six modèles est qu'ils peuvent être expérimentés sans restructuration générale. Un pod, un flux support, une équipe finance ou un service technique suffisent souvent à vérifier l'hypothèse.

Auto-diagnostic — quel modèle mérite d'être testé chez vous ?

Pour chaque modèle, cochez les affirmations vraies aujourd'hui.

A. Adoption distribuée

• •Plusieurs équipes utilisent déjà l'IA de manière autonome.
• •Les usages intéressants circulent mal ou sont reconstruits plusieurs fois.
• •Les équipes ont assez de compétences pour être autonomes si un socle commun et des relais existent.

3 cases cochées : testez un modèle distribué structuré — sponsor, noyau plateforme léger, relais dans les équipes.

À éviter si : les contraintes réglementaires ou la rareté des compétences exigent encore un contrôle central important.

B. Centre d'excellence centralisé

• •Les compétences nécessaires sont rares et concentrées chez quelques personnes.
• •Les risques data, sécurité ou conformité imposent des standards communs forts.
• •Plusieurs équipes ont besoin des mêmes briques, plateformes ou méthodes.

3 cases cochées : un centre d'excellence peut réduire la duplication et sécuriser le déploiement.

À surveiller dès le premier jour : délai de traitement des demandes et dépendance des métiers au centre.

C. Équipe produit hybride

• •Vos PM, designers et ingénieurs empiètent déjà utilement sur leurs périmètres respectifs.
• •Les handoffs entre spécialités ralentissent davantage l'équipe qu'ils ne protègent la qualité.
• •Des spécialistes restent disponibles pour la review ou les problèmes complexes.

3 cases cochées : testez un pod plus généraliste sur un périmètre limité.

À ne pas faire : supprimer des expertises avant d'avoir démontré qu'elles peuvent être mobilisées autrement.

D. Humain sur les exceptions

• •Votre activité comporte un volume important de cas répétitifs.
• •Il est possible de déterminer objectivement ce qui constitue un cas standard ou une exception.
• •Vous savez mesurer erreurs, rework, qualité et taux d'exception.

3 cases cochées : un modèle « humain sur les exceptions » mérite un pilote.

Question obligatoire : à quoi ressemblera le travail des personnes qui ne recevront plus que les dossiers difficiles ?

E. Développement agentique

• •Les agents produisent déjà une part significative du travail de développement.
• •Vos specs, tests et critères d'acceptation sont suffisamment explicites.
• •La review ou la capacité de décision commence à devenir plus limitante que l'écriture du code.

3 cases cochées : le sujet n'est probablement plus l'achat d'un nouvel outil, mais la transformation du workflow engineering.

À mesurer : temps total jusqu'à la mise en production et rework — pas seulement le volume de code généré.

F. Organisation AI-native

• •L'IA est constitutive du produit ou du service depuis la création de l'entreprise.
• •Votre architecture, votre culture et vos recrutements ont été conçus autour de cette réalité.
• •Vous n'avez pas à faire migrer une organisation historique vers ce modèle.

3 cases cochées : les entreprises AI-native peuvent fournir des références organisationnelles directement pertinentes.

Sinon : utilisez-les comme scénarios limites et sources d'idées — pas comme benchmark d'effectif ou modèle cible.

Si plusieurs modèles obtiennent trois réponses positives

C'est probablement normal. Votre véritable operating model est peut-être une combinaison : centre d'excellence pour la plateforme et la gouvernance, adoption distribuée dans les métiers, humain sur les exceptions dans les opérations, développement agentique dans certaines équipes techniques. La prochaine étape n'est pas de choisir une étiquette — c'est de préciser les interfaces entre ces modèles.

Ma conviction

L'IA ne crée pas une nouvelle organisation idéale. Elle rend plus visibles les défauts de l'organisation existante.

Elle révèle les handoffs inutiles, les décisions mal attribuées, les compétences devenues rares, les tâches répétitives, les problèmes de qualité, les goulots de review.

C'est pourquoi deux entreprises utilisant les mêmes modèles et les mêmes outils peuvent avoir intérêt à construire des organisations très différentes.

Le rôle d'un dirigeant n'est pas de rejoindre au plus vite le modèle jugé le plus avancé. Il est de déterminer où doit rester l'expertise, où doit se prendre la décision, où placer le contrôle, et quelles responsabilités l'organisation ne souhaite pas déléguer.

Le meilleur operating model sera celui qui répond à ces questions avec assez de clarté pour permettre aux équipes de travailler différemment — sans déplacer silencieusement le risque ailleurs.