L'écart des trente-huit points

En 2024, la différence d’adoption de l’IA entre grandes et petites entreprises de l’UE était de 30 points de pourcentage. En 2025, elle est de 38. Les outils sont devenus moins chers. Les interfaces se sont simplifiées. L’écart s’est élargi.

Ce n’est pas une prévision. C’est une mesure. Le communiqué d’Eurostat du 11 décembre 2025 indique que 55 % des grandes entreprises (250 salariés et plus) ont utilisé des technologies d’IA en 2025, contre 17 % des petites entreprises (10-49). Un an plus tôt, la même enquête montrait 41 % et 11 %. L’écart s’est creusé l’année où les outils étaient censés se démocratiser.

Ce n’est pas un problème de sensibilisation. C’est un problème d’architecture.

Ce que disent les chiffres

L’enquête communautaire d’Eurostat sur l’utilisation des TIC dans les entreprises est la référence européenne. Échantillon : environ 157 000 entreprises dans les 27 États membres, d’au moins 10 salariés. La vague 2025 a été publiée le 11 décembre 2025. Le titre — 20 % des entreprises de l’UE utilisent l’IA — a été repris partout. La ventilation par taille, non.

Voici la donnée par classe de taille, d’une année sur l’autre :

Les petites entreprises sont passées de 11 % à 17 % — six points de croissance. Les grandes entreprises sont passées de 41 % à 55 % — quatorze. Les entreprises moyennes (50-249) sont passées de 21 % à 30 %. Toutes les classes de taille ont progressé. Les plus grandes ont progressé le plus vite.

Le rapport Ipsos Making AI Work for Europe, commandé par Google et publié en mars 2026 par Reece Decastro et Nathan Bransden, nomme le schéma en une phrase : « Les grandes entreprises sont nettement plus susceptibles d’adopter l’IA que les petites et moyennes entreprises (PME), cet écart s’étant creusé de 30 points de pourcentage en 2024 à 38 points en 2025. » Les auteurs s’appuient sur environ 70 études et 15 entretiens d’experts dans 13 États membres de l’UE. Ils tirent la même conclusion que les microdonnées d’Eurostat, puis la nomment.

L’enquête sur l’investissement de la BEI 2025 — méthodologie différente, outils d’IA par marque plutôt que par catégorie technique — rapporte 28 % des PME et 44 % des grandes entreprises utilisant l’IA. Chiffres absolus différents. Même forme. Les PME sont à la traîne, et l’écart ne se referme pas.

La géographie de l’écart est aussi nette que la taille. Les chiffres pays par pays d’Eurostat pour 2025 vont de 42 % au Danemark, 37 % en Finlande, 35 % en Suède — à 5 % en Roumanie, 8 % en Pologne, 8 % en Bulgarie, 9 % en Grèce. La variance n’est pas aléatoire. Elle suit l’infrastructure numérique, pas le PIB. Même chose par secteur : 63 % des entreprises de l’information et de la communication utilisent l’IA ; 40 % des services professionnels, scientifiques et techniques ; 17 % des industriels ; 11 % du transport et de l’entreposage ; 11 % de la construction. Le document de l’OCDE de décembre 2025 pour la réunion ministérielle du G7 à Montréal observe le même schéma à travers les économies du G7 : 40 % des entreprises de 250 salariés et plus utilisaient l’IA en 2024, contre 20,4 % des entreprises entre 50 et 249 et 11,9 % entre 10 et 49. Les noms de pays changent. La forme structurelle, non.

Pourquoi l’écart se creuse quand les outils s’allègent

L’intuition est que des outils plus simples réduisent les écarts. Une interface de chatbot reste une interface de chatbot, qu’on soit chez Siemens ou dans une PME logistique de 30 personnes à Tarragone. Les abonnements sont comparables. Les API cloud sont identiques.

L’intuition est fausse, et la raison est structurelle.

Les grandes entreprises ont trois choses que les petites n’ont pas. La première est une infrastructure numérique dédiée. Un industriel de 500 personnes a un service informatique qui évalue les outils, gère les intégrations, traite la revue de sécurité et absorbe le coût dans une ligne budgétaire existante. Une PME logistique de 30 personnes a une seule personne qui gère le standard téléphonique, le CRM, les imprimantes — et à qui on demande maintenant d’évaluer des outils d’IA en interrompant son vrai travail.

La deuxième est la donnée. Le document de discussion de l’OCDE AI adoption by small and medium-sized enterprises, publié en décembre 2025 par Flavio Calvino et ses collègues pour la réunion ministérielle Industrie, Numérique et Technologie du G7 à Montréal, liste quatre leviers d’adoption de l’IA : connectivité, intrants permettant l’IA, compétences et financement. Les intrants permettant l’IA, ce sont les données — structurées, accessibles, en volume suffisant, suffisamment gouvernées pour alimenter un modèle. Les grandes entreprises ont franchi ce seuil il y a une décennie, en implémentant leurs ERP et leurs entrepôts de données cloud. Les petites, pour la plupart, non. Un outil d’IA qui exige une entrée structurée ne peut rien faire d’un tableau blanc.

La troisième est la capacité à définir un cas d’usage. Le rapport IA Révolution de Bpifrance de 2024 a trouvé que 72 % des dirigeants de PME en France n’ont pas encore d’application pratique de l’IA pour leur entreprise. Pas « n’ont pas déployé » — n’ont pas. Le cas d’usage lui-même n’existe pas dans leur tête. Ils ont entendu parler de l’IA. Ils ne peuvent pas pointer la tâche qu’elle remplacerait.

Quand les outils se simplifient, ceux qui avaient déjà infrastructure, données et cas d’usage vont plus vite. Ceux qui n’avaient aucun des trois sont toujours là où ils étaient. Des outils moins chers ne génèrent pas de cas d’usage. Des interfaces simples ne produisent pas de données structurées. Une API sans friction ne donne pas à une PME de 30 personnes la marge nécessaire pour concevoir un flux de travail.

L’écart se creuse parce que les prérequis se creusent en premier.

L’histoire des compétences n’est que la moitié de l’histoire

La moitié des discussions politiques européennes sur l’écart d’adoption se rabattent sur les compétences. Le rapport Ipsos cite une enquête de l’OCDE menée dans quatre pays du G7 : 50 % des PME déclarent que leurs salariés n’ont pas les compétences pour utiliser l’IA générative. L’enquête D4SME de l’OCDE elle-même, échantillonnant près de 1 000 répondants dans six pays du G7, a trouvé plus de 50 % citant le manque de connaissance sur l’usage de l’IA générative comme barrière à l’adoption — avec une forte variation nationale, de 80 % au Japon à 40 % au Royaume-Uni et en Allemagne.

Le chiffre est réel. Il est aussi incomplet.

Un sondage Public First auprès de dirigeants européens, également cité dans le rapport Ipsos, n’a trouvé que 14 % citant « nous n’avons pas l’expertise pour introduire l’IA » et 12 % citant « nous n’avons pas les compétences pour utiliser l’IA » comme barrières principales — bien en dessous des préoccupations de cybersécurité (26 %), d’inexactitude (24 %) et de coût (22 %). Posée d’une certaine façon, la compétence est la barrière dominante. Posée autrement, c’est une barrière parmi plusieurs.

Ce que les données montrent réellement, quand on lit à travers les enquêtes plutôt qu’à l’intérieur, c’est ceci : les compétences sont corrélées à l’adoption, mais les compétences sont en aval de la structure. Un universitaire interrogé pour le rapport Ipsos le dit simplement : « Ce n’est pas la taille… c’est vraiment lié à la maturité numérique. » Un représentant de think tank belge dans la même étude : « Les PME sont déjà plus lentes sur la numérisation de base, donc construire de l’IA par-dessus est encore plus difficile. »

L’enquête de l’OCDE ajoute le fait opérationnel qui détermine tout : moins de 30 % des PME utilisant déjà de l’IA générative déclarent que leurs salariés participent à des formations liées à l’IA. La fourchette va de 11,3 % au Japon à 29,4 % au Canada. Le problème de formation n’est pas que la formation n’existe pas. Le problème de formation, c’est que le temps pour la suivre n’existe pas — parce que les PME ne peuvent pas libérer des salariés d’activités qui génèrent du revenu pour apprendre. L’écart de compétences est, en partie, un écart de temps qui se déguise en écart d’aptitude.

On ne ferme pas un écart structurel avec des campagnes de sensibilisation. On le ferme avec de l’architecture.

Ce que l’architecture veut dire concrètement

Dans un contexte PME, « architecture » n’est pas une diapositive avec cinq cases et des flèches. Ce sont quatre décisions opérationnelles, prises dans l’ordre.

Un : la préparation des données. Avant tout outil d’IA, l’entreprise doit savoir quelles données elle a, où elles vivent, comment elles circulent et ce qui manque. La plupart des PME ne peuvent pas répondre à ces quatre questions le lundi matin. Le premier mois d’un déploiement d’IA n’est pas un modèle. C’est un audit de données : factures, fiches clients, informations fournisseurs, journaux opérationnels. Où sont-elles. Comment sont-elles stockées. Qui les possède. Qu’est-ce qui est cassé. Tant que ce n’est pas cartographié, chaque outil d’IA repose sur des fondations que personne n’a inspectées.

Deux : un cas d’usage défini, assez étroit pour être livré. Pas « améliorer le service client avec de l’IA ». Une tâche spécifique, une personne spécifique, une fréquence spécifique : classer les e-mails clients entrants par urgence, router vers la bonne équipe, le faire en moins de soixante secondes, mesurer le taux d’escalade chaque semaine. La taxonomie de l’OCDE dans le même document de décembre 2025 distingue les Novices, Explorateurs, Optimiseurs et Champions de l’IA. Le saut de Novice à Optimiseur ne se produit pas parce que les outils s’améliorent. Il se produit parce qu’un cas d’usage concret est livré, puis un deuxième. Les cas d’usage se composent. Les stratégies, non.

Trois : un déploiement par rôle. Les outils d’IA ne sont pas déployés à une entreprise. Ils sont déployés à un rôle. La personne qui classe les factures a besoin d’un outil différent, d’une interface différente et d’une formation différente de la personne qui rédige les communications clients. Un seul « déploiement IA » adressé à « l’équipe » produit un seul taux d’abandon : élevé. Le déploiement par rôle — un rôle à la fois, avec le flux de travail examiné, l’outil configuré pour ce flux et l’utilisateur formé à l’utiliser à l’intérieur de son vrai travail — produit l’adoption. Ce n’est pas une préférence méthodologique. C’est ce que le corpus d’études de cas de PME montre.

Quatre : la mesure d’adoption dès le premier jour. Pas « l’avons-nous déployé ». Les gens l’ont-ils utilisé la semaine dernière, dans leur vrai travail, pour la tâche prévue. Usage actif quotidien par rôle. Mesure hebdomadaire de résultat — moins d’escalades, délais plus courts, prévisions plus précises. Le rapport Ipsos relie cela à la capacité organisationnelle : « La création de valeur par l’IA dépend de la capacité organisationnelle. » Un outil que personne n’a utilisé la semaine dernière n’a créé aucune valeur la semaine dernière, peu importe le prix payé.

Ces quatre points ne sont pas un programme de transformation. C’est l’architecture minimale pour un seul outil d’IA livré. Les entreprises des 17 % ont bouclé la boucle sur ces quatre points. Celles des 83 % ne l’ont pas fait — et les raisons pour lesquelles elles ne l’ont pas fait sont structurelles, pas motivationnelles.

Un exemple concret

Une forme spécifique clarifie l’abstraction. Un fabricant spécialisé de 40 personnes dans le nord du Portugal — type réel, anonymisé — voulait « utiliser l’IA » pour le service client. La première conversation a fait remonter le vrai problème : un seul responsable d’exploitation passait quatre à six heures par semaine à trier les e-mails clients par urgence et à les router vers la bonne équipe d’atelier. Le volume augmentait. Le responsable était le goulot.

Voilà le cas d’usage. Pas « l’IA pour le service client ». Trier les e-mails clients entrants par urgence, classer par famille de produit, router vers la bonne équipe, mesurer le temps de réponse. Un rôle. Une tâche. Mesurable en une semaine.

L’audit de données a pris cinq jours ouvrés. Les e-mails existaient dans une boîte partagée. La taxonomie produit existait dans l’ERP. Les règles de routage existaient dans la tête du responsable. Deux des trois n’étaient pas sous forme structurée — les règles de routage ont dû être extraites lors d’une demi-journée avec le responsable, écrites, et transformées en schéma de classification. Le schéma est le vrai livrable de la première semaine. Le modèle est le livrable de la deuxième.

L’outil, quand il a été livré, était petit. Il lisait les e-mails entrants, appliquait le schéma, attribuait un niveau d’urgence et une famille de produit, et poussait le message dans la file de la bonne équipe. Le responsable a gardé le bouton de remplacement. L’usage actif quotidien a commencé le jour de la livraison. Mesure hebdomadaire : le délai moyen de réponse est passé de quarante et une heures à neuf. Le responsable a récupéré quatre heures par semaine. L’équipe a cessé de manquer des messages urgents des plus gros comptes.

L’architecture, c’était le travail. Le modèle, c’était douze lignes d’appels API. Le coût de la construction n’était pas le modèle — c’était le schéma, l’audit, la définition du rôle et l’accord sur ce à quoi ressemblait le succès, avant tout déploiement. Voilà à quoi ressemble fermer l’écart à l’échelle d’une unité.

Ce que Bluewaves voit

La première conversation avec chaque prospect Bluewaves passe par les quatre points ci-dessus, dans l’ordre. Environ un tiers des conversations s’arrête au premier. L’entreprise n’a pas de données structurées, pas de système de référence, ne sait pas où vit son information opérationnelle. Le travail dont elle a besoin n’est pas un déploiement d’IA. C’est la fondation numérique que l’IA exige. On le dit. On ne prend pas la mission tant que la fondation n’est pas en place — ou jusqu’à ce que l’entreprise décide que mettre la fondation en place soit la mission.

Environ un tiers s’arrête au deuxième. L’entreprise a des données, de l’intérêt, un budget, mais pas de cas d’usage assez étroit pour livrer en trois semaines. Le premier livrable pour ces entreprises n’est pas un modèle. C’est un atelier de cas d’usage avec les personnes qui utiliseraient effectivement l’outil, conçu pour quitter la pièce avec une tâche spécifique, étroite et mesurable. Ensuite on construit.

Le dernier tiers arrive avec les quatre points déjà en place — données, cas d’usage défini, rôle identifié, volonté de mesurer. Ces déploiements sont livrés en trois semaines et restent en usage parce que les prérequis étaient remplis avant l’écriture du code.

Ce n’est pas une méthode commerciale. C’est la réalité opérationnelle de pourquoi l’écart Eurostat se creuse. Les entreprises des 17 % ont franchi des seuils que celles des 83 % n’ont pas franchis. Le franchissement ne s’achète pas avec des licences logicielles.

La position architecturale

L’écart se creuse parce que les conditions pour le fermer ne sont pas dans les outils. Elles sont dans les entreprises. Une API moins chère ne produit pas de préparation des données. Une interface plus simple ne produit pas de cas d’usage. Un chatbot plus aimable ne donne pas à une PME de 30 personnes la marge pour concevoir un flux de travail. La structure doit venir d’abord, et la plupart des PME n’ont reçu aucune aide pour la construire — parce que l’aide, dans la conversation politique européenne, a été définie comme formations, webinaires, campagnes de sensibilisation et financement de pilotes. Ce n’est pas de l’architecture. C’est du commentaire.

Le rapport Ipsos cite des travaux de la Copenhagen Business School qui nomment l’architecture honnêtement : « La création de valeur par l’IA dépend de la capacité organisationnelle. » Voilà la phrase. La capacité organisationnelle est le goulot. La capacité se construit par la structure, pas par le contenu. Le deuxième principe du rapport adressé aux décideurs publics est cohérent : « Soutenir le développement de la capacité et de la disponibilité organisationnelles. » Pas plus de formation. De la capacité.

Si la vague Eurostat 2026 est publiée en décembre et montre un écart de 40 points, personne ne devrait être surpris. Les mêmes conditions sont en place. Les mêmes prérequis sont absents. Le même appareil de soutien continue à traiter la sensibilisation plutôt que l’architecture. L’écart fait exactement ce que ses causes structurelles prédisent.

Le fermer demande une intervention différente. Pas plus de pilotes. Pas plus d’études de cas. Pas plus de webinaires. Des outils pré-qualifiés pour des cas d’usage pré-définis, pré-cartographiés au rôle et aux données dont l’entreprise dispose déjà. Du portage externe quand le portage interne n’existe pas. Une mesure d’adoption qui commence dès le premier jour, pas après la troisième revue trimestrielle.

Voilà la correction architecturale. Tout le reste est théâtre. L’écart est structurel. La correction est structurelle. Les outils moins chers et les interfaces plus simples sont réels — et ils continueront à creuser l’écart tant que les prérequis ne seront pas adressés à la même vitesse que les outils s’améliorent.

Trente-huit points l’année dernière. Le chiffre sera plus grand l’année prochaine, à moins que le soutien cesse d’être du contenu et devienne de la structure.