La dispersion de l’IA dans les PME danoises n’est pas un problème d’IA. C’est un problème de responsabilité sur les coûts et les risques.

Donnez un outil puissant à des personnes compétentes : elles vont l’utiliser. Là-dessus, rien de surprenant.

Ce qui l’est tout autant, mais dont on parle moins, c’est la suite : un outil devient dix. Puis vingt. Les licences se glissent dans les notes de frais. Des textes sensibles finissent collés dans des prompts. Les équipes bricolent des petits workflows que personne ne revoit. Personne n’est malveillant. Personne ne fait du « shadow IT » volontairement. Ils essaient simplement de faire leur travail.

C’est pour cela que je ne suis pas étonné de lire que une PME danoise sur deux a perdu le contrôle de son propre usage de l’IA, ni que une entreprise sur trois dotée d’une stratégie IA ne parvient toujours pas à maîtriser l’usage. Le titre présente cela comme une défaillance de leadership. Je suis d’accord. Mais pas au sens moral : c’est un défaut de conception.

La plupart des entreprises tentent de traiter la dispersion de l’IA avec des politiques et de la formation. C’est nécessaire, mais insuffisant. Le goulot d’étranglement, c’est le modèle opérationnel : qui porte la dépense, qui porte le risque, et à quoi ressemble le « bon » en termes de résultats mesurables.

Le schéma derrière la dispersion de l’IA : c’est toujours la voie la plus simple qui gagne

La dispersion de l’IA n’a rien d’un mystère. C’est le résultat naturel de trois incitations qui se percutent.

• On récompense les salariés sur la vitesse, pas sur l’hygiène des outils. Si un nouvel assistant fait gagner 30 minutes aujourd’hui, il sera adopté aujourd’hui.
• Les budgets sont morcelés. Chaque équipe a une petite marge de manœuvre, et personne ne voit le total avant que cela ne devienne gênant.
• Le risque reste abstrait… jusqu’au jour où il ne l’est plus. Fuites de données et sujets de conformité paraissent théoriques, jusqu’au premier incident ou audit.

Mettez ces trois éléments ensemble et vous obtenez exactement ce que décrit l’article sur les PME danoises : les salariés choisissent leurs outils, tandis que le management ne peut ni voir, ni contrôler, ni standardiser l’usage, même quand une « stratégie » existe sur le papier.

Règle simple : si vous ne pouvez pas répondre à « qui paie la facture ? » et « qui peut couper ? » en cinq secondes, vous n’avez rien gouverné. Vous avez seulement formalisé des intentions.

Arrêtez de parler de « stratégie IA » quand il s’agit en réalité d’achats + sécurité + productivité

La plupart des déploiements d’IA échouent en silence parce qu’on les traite comme un choix technologique ou une initiative d’innovation. Dans les faits, l’usage quotidien de l’IA ressemble plutôt à trois fonctions qui doivent travailler de concert :

• Achats : quels outils sont autorisés, à quelles conditions contractuelles, avec quelles clauses de renouvellement et de sortie.
• Sécurité et gouvernance des données : ce qui peut être partagé, où cela peut être traité, et ce qui doit être journalisé.
• Pilotage de la productivité : quels résultats vous visez et comment vous mesurez si les outils « méritent » leur place.

Si vous gérez ces trois sujets dans des conversations séparées, vous créez de la dispersion. Si vous les organisez comme un seul système, vous accumulez l’apprentissage et réduisez le risque.

C’est aussi pour cela que je préfère parler de « perte de contrôle » plutôt que de « manque d’adoption de l’IA ». L’adoption n’est plus rare. L’usage cohérent, si.

J’ai déjà écrit que le sovereign compute est un modèle opérationnel, pas un simple changement de fournisseur. L’IA dans les PME relève du même type de problème. Les outils sont la partie visible. La responsabilité et les processus, ce sont les rouages.

La correction la plus simple qui marche : nommer un responsable des dépenses IA

La plus grosse erreur que je vois, c’est de considérer que le coût de l’IA est « trop faible pour être piloté ». C’était vrai quand il s’agissait d’un pilote. Ça cesse de l’être dès que l’IA devient la manière par défaut d’écrire, de résumer, de coder, de concevoir et d’analyser.

Ma recommandation, sans détour : nommez un responsable des dépenses IA. Une personne redevable de la facture totale et de la valeur totale. Pas un gardien qui valide chaque prompt, mais quelqu’un qui rend les arbitrages visibles.

Ce responsable fait trois choses, avec constance :

1. Définir l’ensemble des outils autorisés (et le chemin pour en ajouter un nouveau).
2. Définir des classes de données et préciser quelles classes sont permises dans quels outils.
3. Organiser une revue mensuelle où l’on compare la dépense à des résultats mesurables, en incluant la posture de sécurité.

C’est tout. Pas de théâtre. Pas de « center of excellence » sauf si vous avez la taille pour le justifier. Juste une responsabilité clairement rattachée à l’argent et au risque.

Un exemple vécu. J’ai vu un écosystème d’outils cloud se multiplier dans une organisation produit parce que chaque équipe optimisait localement. Il a fallu un trimestre pour réaliser qu’on avait trois contrats qui se recoupaient, un contrôle d’accès incohérent et aucune journalisation partagée. La partie technique se réglait en quelques semaines. Le nettoyage a pris des mois, parce que personne ne pouvait dire de manière crédible : « voici le chemin unique approuvé, et voici la facture si nous ne consolidons pas ». Le jour où nous avons désigné un responsable de la dépense et un responsable de la frontière de données, les discussions ont changé. Pas par magie. Mais de façon mesurable.

Définissez « outils autorisés » et « classes de données » comme si vous le pensiez vraiment

La plupart des politiques IA échouent parce qu’elles sont soit trop vagues (« attention aux données sensibles »), soit trop strictes (« n’utilisez jamais l’IA »). Vous avez besoin de règles applicables.

1) Outils autorisés (une liste courte, pas une encyclopédie)

Construisez une liste par niveaux :

• Tier A (par défaut) : autorisé pour un usage général, intégré au SSO, journalisé, avec des termes contractuels clairs.
• Tier B (restreint) : autorisé pour des rôles ou des projets spécifiques, avec des contrôles supplémentaires.
• Tier C (bloqué) : interdit en raison du traitement des données, de l’absence de contrôles entreprise ou de conditions floues.

Ne cherchez pas la perfection. Cherchez la lisibilité. Les gens suivent des règles qu’ils peuvent retenir.

2) Classes de données (cinq suffisent généralement)

Définissez un petit nombre de catégories. Par exemple :

• Public : contenus marketing, documents publiés.
• Interne : information opérationnelle non sensible.
• Confidentiel : données clients, prix, contrats, informations financières internes.
• Réglementé : tout ce qui comporte des obligations légales particulières.
• Secrets : identifiants, clés privées, détails de sécurité.

Ensuite, formalisez une matrice claire : quelle classe de données est autorisée dans quel tier d’outils. Si le « confidentiel » n’est autorisé qu’en Tier A, le message devient simple à communiquer et à faire respecter.

Pour se représenter la chose, voyez-y l’équivalent IA de « ce qui peut passer par email ». Tout le monde comprend déjà que certains contenus n’ont rien à faire dans le mauvais canal.

Mesurez les résultats, pas l’enthousiasme : le contrat de productivité

L’adoption de l’IA est facile à célébrer, parce que cela ressemble à de l’activité. Ce qu’il vous faut, c’est un contrat de productivité : un cadre qui transforme l’usage en résultats.

Choisissez quelques workflows importants et mesurez-les avant et après. Pas tout. Juste là où le temps et la qualité se voient.

• Ventes : délai pour produire une première version de proposition, taux de conversion des séquences d’outbound, délai entre lead et opportunité qualifiée.
• Support client : délai de première réponse, temps de résolution, taux de déviation (deflection), taux d’escalade.
• Engineering : cycle time pour de petites évolutions, défauts qui échappent aux contrôles, temps passé en code review.
• Finance et ops : délai de clôture, effort de rapprochement, taux de traitement des exceptions.

L’objectif n’est pas de prouver que l’IA « marche ». L’objectif est d’apprendre où elle paie, où elle crée de nouveaux risques, et où elle n’est qu’un divertissement facturé en abonnement.

C’est aussi là que beaucoup d’entreprises se font piéger par les demos. Une demo montre ce qui est possible. Un workflow impose une responsabilité. Si vous voulez un schéma plus robuste pour transformer l’IA en capacité livrée, un playbook vaut mieux qu’une demo.

Cadence mensuelle : une gouvernance légère

La gouvernance n’a pas besoin d’être lourde. Elle doit être assez fréquente pour détecter la dérive tôt.

Voici une cadence mensuelle qui fonctionne dans les petites entreprises sans étouffer l’initiative :

• Revue des dépenses : dépense IA totale par outil et par équipe, nouveaux abonnements, renouvellements dans les 60 prochains jours.
• Exceptions outils : qui utilise des outils non approuvés et pourquoi ; décision : approuver, remplacer ou bloquer.
• Incidents de frontière de données : violations signalées, quasi-incidents, cas ambigus qui imposent une meilleure règle.
• Indicateurs de résultats : 2 à 5 métriques de workflow, tendances, ce qui a changé, ce qui sera testé le mois suivant.
• Kill list : outils ou pilotes à arrêter, avec une date explicite.

C’est la partie que la plupart des entreprises évitent. Arrêter quelque chose donne l’impression d’admettre un échec. En réalité, c’est ce qui permet d’apprendre à moindre coût.

Un autre lien sur le même thème, sous un angle différent : procurement without exit ramps, c’est la manière dont les coûts IA deviennent permanents, même quand la valeur n’apparaît jamais.

Mon avis : la liberté totale va bien deux semaines, ensuite il faut un système

Je ne suis pas opposé à l’expérimentation. Laissez les gens explorer. C’est comme cela que vous trouvez les cas d’usage inattendus.

Mais l’exploration a une demi-vie. Après le premier pic, l’usage non piloté se transforme en trois coûts bien réels :

• Financier : abonnements en doublon, renouvellements opaques, facture que personne n’explique.
• Sécurité et conformité : les données partent là où elles ne devraient pas, et vous ne pouvez pas prouver ce qui s’est passé.
• Organisationnel : chacun apprend des outils différents, construit des façons de travailler incompatibles, et vous perdez la réutilisation.

Alors oui, appelez cela une défaillance de leadership si vous voulez. Moi, je préfère un terme plus actionnable : une défaillance de responsabilité.

Nommez un responsable des dépenses IA. Définissez les outils autorisés. Définissez les classes de données. Faites une revue mensuelle. Mesurez les résultats. Arrêtez ce qui ne mérite pas sa place.

C’est comme cela que vous gardez l’IA utile, sûre et abordable. Pas en demandant aux équipes de s’auto-gouverner, à coups de bonnes intentions, sur un sujet d’achats et de sécurité.