Maturité IA des PME françaises 2025-2026

Préambule : passer de l’usage à la capacité

L’adoption de l’IA progresse vite dans les petites entreprises, mais un taux d’usage ne dit ni si les processus ont changé, ni si la valeur est mesurée, ni si les risques sont maîtrisés : la maturité décrit une capacité organisationnelle, pas la présence d’un outil.

• Le Baromètre France Num 2025 mesure 26 % de TPE-PME utilisant au moins une solution d’IA, sur 11 021 entreprises interrogées [1].
• Le plan public « Osez l’IA » vise 80 % des PME et ETI utilisatrices en 2030 ; cette cible ne correspond à aucun niveau Junyr [2].
• KPMG identifie 11 % d’« AI leaders » dans un échantillon mondial d’entreprises réalisant au moins 100 M$ de chiffre d’affaires, dont les trois quarts dépassent 1 Md$ ; ce résultat éclaire l’écart entre expérimentation et passage à l’échelle, sans estimer la maturité des PME françaises [3].
• Le livre blanc transforme ces constats en décisions : diagnostiquer, choisir un cas d’usage, préparer les données et la gouvernance, puis mesurer avant d’étendre.

La thèse de travail est que l’avantage durable vient de la capacité à choisir, intégrer, contrôler et améliorer l’IA dans les opérations, car les modèles et leurs tarifs changent plus vite que les processus, les responsabilités et les preuves de valeur.

• Choisir : relier chaque cas d’usage à un problème métier, un propriétaire et un indicateur.
• Intégrer : traiter les données, les droits, les interfaces et les changements de rôle avant l’automatisation.
• Contrôler : fixer les décisions réservées à l’humain, journaliser les actions et prévoir l’arrêt.
• Améliorer : comparer les résultats au point de départ et réviser le dispositif à chaque cycle.

Chapitre 1 : lire correctement l’état des lieux

Les enquêtes disponibles mesurent des populations et des objets différents ; elles deviennent utiles pour une PME quand on sépare clairement adoption, profondeur d’usage, création de valeur et gouvernance au lieu de les fondre dans un taux unique.

• Adoption : France Num demande si l’entreprise utilise une solution d’IA ; les usages dominants restent la génération de contenu et les assistants [1].
• Profondeur : l’automatisation de tâches et l’analyse de données sont beaucoup moins répandues que l’IA générative de surface dans la même enquête [1].
• Valeur : KPMG indique que 64 % de son échantillon de grandes organisations rapporte des résultats métier significatifs, tandis que ses 11 % d’AI leaders se distinguent par la maturité et le déploiement d’agents [3].
• Gouvernance : la présence d’une politique, de responsables, de contrôles et de mesures doit être observée directement ; aucun taux d’adoption ne permet de l’inférer.

Les écarts entre enquêtes ne sont donc pas des contradictions automatiques : France Num porte sur les TPE-PME françaises, KPMG sur de grandes organisations mondiales, et les études de fournisseurs ou de cabinets décrivent souvent des dirigeants, des fonctions ou des projets plutôt qu’une population nationale comparable.

• Conserver la définition exacte de l’indicateur avant de reprendre un pourcentage.
• Mentionner la taille, la géographie et la date de l’échantillon lorsque le résultat guide une décision.
• Présenter les associations comme des associations, sans en faire une causalité ou une probabilité de succès pour un client.
• Réserver les retours de mission à l’amélioration de la méthode tant que leur protocole et leur base ne sont pas publiés.

Le coût de l’attentisme ne se résume pas à une disparition annoncée des retardataires ; il se matérialise lorsque des usages non gouvernés se diffusent, que les données restent inexploitables ou qu’un concurrent apprend plus vite sur un processus décisif.

• Cartographier les usages déjà présents, y compris les comptes individuels et les fonctions intégrées aux logiciels.
• Identifier un processus où le délai, la qualité ou la charge sont effectivement mesurables.
• Décider ce qui doit être appris maintenant et ce qui peut attendre une technologie plus stable.
• Protéger les options de sortie : données exportables, contrats réversibles et intégrations documentées.

AI Act : raisonner par rôle, système et usage

Le règlement européen ne crée pas une obligation uniforme pour toute « IA d’entreprise » : le travail commence par qualifier le rôle de l’organisation, le système concerné et son usage, puis par appliquer les obligations et dates correspondantes avec un conseil juridique si l’enjeu le justifie [4][5].

• L’organisation peut être fournisseur, déployeur, importateur ou distributeur selon ce qu’elle développe, commercialise et exploite.
• Le niveau de risque dépend de l’usage ; un même modèle peut alimenter un cas courant ou un système à haut risque.
• Le règlement (UE) 2026/1744 a modifié l’article 4 : fournisseurs et déployeurs soutiennent le développement de la culture IA, sans garantir un niveau précis pour chaque personne [5].
• Les sections applicables aux systèmes à haut risque de l’annexe III prennent effet le 2 décembre 2027 ; celles liées à l’annexe I le 2 août 2028, sous les règles transitoires du texte [5].
• Atteindre un niveau Junyr facilite l’inventaire, les responsabilités et les preuves, mais ne constitue jamais une garantie de conformité.

Chapitre 2 : l’Échelle Méthode Junyr™

L’Échelle Junyr™ est une grille de décision propriétaire en cinq niveaux qui décrit la capacité d’une organisation à transformer un usage individuel en système mesuré et gouverné, avec des preuves cumulatives adaptées au contexte de la PME.

Les niveaux sont cumulatifs : une architecture sophistiquée ne compense pas l’absence de propriétaire métier, et un grand nombre d’utilisateurs ne compense pas l’absence de contrôle, de mesure ou de procédure d’incident.

• Un outil acheté ne fait pas monter d’un niveau ; une capacité démontrée et répétable le fait.
• Un cas d’usage isolé peut être avancé alors que l’organisation reste Artisan dans son ensemble.
• Le niveau doit être documenté par dimension et réévalué après un changement majeur de processus, de fournisseur ou de réglementation.
• Les budgets et délais se chiffrent à partir du périmètre, de la dette de données, des intégrations et des exigences de risque propres à l’entreprise.

Les neuf dimensions à examiner

Le référentiel Junyr examine neuf dimensions distinctes qui, ensemble, décrivent le passage d’usages individuels à une capacité durable ; chaque axe progresse qualitativement et s’appuie sur des preuves observables adaptées à l’entreprise.

• Souveraineté et contrôle des modèles : origine des services, localisation et usage des données, maîtrise des clés, conditions contractuelles et capacité de changer de modèle.
• Résilience et continuité : dépendances critiques, sauvegardes, modes dégradés, reprise, portabilité et tests de sortie en cas de panne ou de rupture fournisseur.
• Collaborateurs augmentés : rôles éligibles, outils approuvés, qualité d’usage, assistance accessible et maintien d’une responsabilité humaine claire.
• Acculturation et culture IA : connaissances adaptées aux métiers, compréhension des limites, formation continue et capacité à vérifier ou contester un résultat.
• Gouvernance IA : sponsor, propriétaires, politiques, registre, dialogue social, arbitrages et supervision proportionnée au risque.
• Dette technique : scripts, intégrations, dépendances, documentation, tests et backlog nécessaires pour conserver un système maintenable.
• Sécurité : classification, identités, secrets, journalisation, évaluation des menaces, incidents et chaîne de fournisseurs.
• Workflows et agents : cas d’usage intégrés aux processus, outils autorisés, limites d’autonomie, validations humaines, évaluation et procédure de repli.
• Valeur et FinOps : baseline, adoption, qualité, TCO, bénéfices attribuables, coût par résultat et sensibilité des hypothèses.

La progression se lit axe par axe : le niveau global correspond au palier le plus élevé dont les capacités essentielles sont établies sur l’ensemble du périmètre retenu.

Auto-évaluation en douze questions

Ce questionnaire sert à préparer un entretien de diagnostic : les réponses sont des preuves à réunir et les niveaux supérieurs exigent tous leurs prérequis, ce qui empêche un bon score global de masquer une lacune critique.

• Q1. Les outils réellement utilisés, y compris les comptes individuels, sont-ils inventoriés ?
• Q2. Les collaborateurs connaissent-ils les données et usages interdits, permis ou soumis à validation ?
• Q3. Chaque cas prioritaire a-t-il un sponsor, un propriétaire métier et un indicateur ?
• Q4. Une baseline de délai, qualité, coût ou risque existe-t-elle avant le pilote ?
• Q5. Au moins un usage récurrent fonctionne-t-il en production avec une procédure de repli ?
• Q6. Adoption, qualité, incidents, coûts et impact sont-ils revus ensemble chaque mois ?
• Q7. Le registre qualifie-t-il le rôle de l’entreprise, l’usage, les données, le fournisseur et le risque ?
• Q8. Les identités, droits, secrets, journaux et intégrations sont-ils contrôlés et testés ?
• Q9. Le TCO et le ROI sont-ils calculés sur une période et un périmètre explicites ?
• Q10. Les changements de modèle, incidents et sorties de fournisseur ont-ils une procédure propriétaire ?
• Q11. Plusieurs processus ont-ils été repensés avec des limites d’autonomie et une supervision proportionnée ?
• Q12. Les résultats, risques et contrôles sont-ils vérifiés par une fonction indépendante du projet lorsque le risque le demande ?

L’interprétation repose sur des portes de passage plutôt que sur une addition interchangeable de « oui » : on retient le niveau le plus élevé dont toutes les preuves essentielles sont présentes.

• Spectateur : Q1 ou Q2 manque encore ; la priorité est la visibilité et la règle d’usage.
• Artisan : Q1-Q2 sont établies, mais une ou plusieurs preuves Q3-Q6 manquent.
• Orchestre : Q1-Q6 sont établies ; les usages sont coordonnés et suivis.
• Architecte : Q1-Q10 sont établies ; la plateforme et la gouvernance sont opérables.
• Pionnier : Q1-Q12 sont établies sur plusieurs processus, avec résultats durables et examen indépendant adapté au risque.

Chapitre 3 : cinq erreurs qui bloquent le passage à l’échelle

Les échecs de déploiement viennent souvent d’un enchaînement de décisions évitables plutôt que d’une faiblesse intrinsèque du modèle ; ces cinq erreurs couvrent le choix du problème, le passage en production, la conduite du changement, l’économie et les données.

• Le gadget : partir d’un outil et chercher ensuite un problème ; antidote, partir d’un irritant mesuré et d’un propriétaire.
• Le POC perpétuel : tester sans critère d’entrée en production ni date de décision ; antidote, fixer avant le pilote les seuils de qualité, coût, adoption et risque.
• Le dirigeant solitaire : confier l’IA à une personne sans temps, mandat ou relais métier ; antidote, répartir sponsor, propriétaire, technique, risque et utilisateurs référents.
• Le ROI immédiat : annoncer un gain avant baseline ou confondre capacité libérée et économie de trésorerie ; antidote, mesurer sur une période explicite et suivre les coûts complets.
• La cécité aux données : automatiser un processus dont les sources, droits et exceptions ne sont pas maîtrisés ; antidote, préparer un corpus minimal fiable avant l’intégration.

La règle « aucun niveau ne se saute » est une règle de séquençage, pas une statistique de défaillance : elle indique que les fondations du niveau précédent doivent être prouvées avant d’ajouter de l’autonomie, des intégrations ou une portée organisationnelle.

• Un pilote peut explorer tôt une technologie avancée dans un environnement isolé.
• Son passage en production exige les contrôles, données, responsables et mesures adaptés à son risque.
• L’investissement augmente seulement lorsque la preuve du palier précédent est suffisante.
• La décision s’appuie sur les critères du pilote et la qualité des fondations, sans appliquer un taux de défaillance générique à une entreprise donnée.

Chapitre 4 : souveraineté et infrastructure

Le choix entre API mondiale, cloud européen, environnement qualifié et déploiement local doit suivre la sensibilité des données, les obligations, la latence, la continuité, le volume et les compétences disponibles ; aucune option n’est souveraine ou rentable par son seul nom.

• Données : où sont-elles traitées, journalisées, sauvegardées et accessibles juridiquement ?
• Contrôle : qui gère les clés, identités, mises à jour, modèles et sous-traitants ?
• Résilience : quelle dégradation reste acceptable en cas de panne réseau, retrait d’un modèle ou incident fournisseur ?
• Portabilité : peut-on exporter les données, évaluations, prompts, journaux et configurations dans un format exploitable ?
• Compétences : l’entreprise peut-elle exploiter, sécuriser et mettre à jour une pile locale sans créer un risque supérieur ?

Comparer l’économie du cloud et de l’on-premise

La rentabilité d’un déploiement local se calcule avec un scénario complet et mesuré, car un volume de tokens ne suffit pas à absorber le matériel, l’énergie, l’exploitation, la redondance, la sécurité et le renouvellement.

• Cloud : consommation entrée/sortie, stockage, réseau, outils, support, pics et remises contractuelles.
• Local : achat ou location du matériel, énergie, hébergement, disponibilité, personnel, mises à jour, sécurité, assurance et valeur résiduelle.
• Comparabilité : même modèle ou niveau de service, même qualité, même latence, même disponibilité et même croissance de charge.
• Décision : retenir le scénario local si son TCO ajusté du risque est meilleur ou si une exigence de contrôle justifie le surcoût.
• Prudence : aux faibles tarifs d’inférence, un usage modeste finance rarement une infrastructure locale par la seule économie de tokens ; la décision exige donc le calcul complet ci-dessus.

La matrice pratique sépare quatre familles de données et adapte l’environnement à leur risque, tout en laissant une analyse spécifique primer sur la catégorie générale.

Juridiction, contrat et accès aux données

La localisation d’un serveur ne suffit pas à décrire l’exposition juridique d’un service : le CLOUD Act peut permettre d’exiger d’un fournisseur soumis à la juridiction américaine des données qu’il contrôle, même stockées à l’étranger, dans le cadre d’une procédure valide [9].

• Examiner les entités contractantes, les sous-traitants et les pays depuis lesquels un accès est possible.
• Faire préciser les règles de réponse aux demandes d’autorités et les possibilités de notification ou de contestation.
• Documenter les mesures techniques et contractuelles adaptées aux données concernées avec le responsable juridique.

Pour choisir un fournisseur, la PME peut demander un dossier court qui transforme les promesses commerciales de souveraineté en engagements vérifiables sur l’exploitation, les données et la capacité de sortie.

• Données : lieux de traitement et de sauvegarde, rétention des entrées et sorties, usage éventuel pour l’entraînement et suppression effective.
• Exploitation : disponibilité attendue, support, accès administrateurs, gestion des incidents et responsabilité des mises à jour.
• Contrôle : identités, clés, journaux exportables, restrictions sur les outils accessibles aux agents et preuves de test.
• Sortie : formats d’export, délai, coûts résiduels et test de reprise sur une solution alternative.

Modèles ouverts, RAG et quantification

Un modèle à poids ouverts donne davantage de choix d’hébergement et d’exploitation, mais sa sélection doit rester fondée sur les tâches de la PME, sa licence, son coût complet et les compétences nécessaires pour maintenir un service fiable.

• Tester les modèles candidats sur le même corpus métier, avec des cas courants, rares et volontairement difficiles.
• Utiliser une recherche documentaire avec sources lorsque la réponse dépend de connaissances internes actualisées ; mesurer aussi les échecs de recherche.
• Envisager une adaptation du modèle seulement si les évaluations révèlent un besoin que les instructions, les outils ou le corpus ne résolvent pas suffisamment.
• Vérifier séparément les droits d’usage des poids, du code et des données : leur disponibilité publique n’efface pas leurs conditions de licence.

La quantification réduit la précision numérique de certains calculs ou paramètres pour diminuer les besoins en mémoire, avec des compromis qui dépendent de la méthode, du matériel et de la qualité attendue ; elle rend certaines configurations possibles sans garantir leur pertinence métier [10].

• Mémoire : dimensionner les poids, le contexte, le cache et le nombre de requêtes simultanées.
• Performance : mesurer le débit et la latence sur le matériel et le moteur réellement utilisés.
• Qualité : comparer les erreurs avant et après quantification sur le jeu d’évaluation métier.
• Exploitation : prévoir les mises à jour, les mesures de sécurité et une capacité de repli.

Préparer la transition cryptographique

La préparation post-quantique répond à la durée de confidentialité des données et au temps nécessaire pour remplacer les composants cryptographiques ; le repère ANSSI de 2027 vise l’entrée en qualification de produits, tandis qu’un calendrier de migration ne prédit pas une date certaine de rupture [8].

• Inventorier les échanges, signatures, certificats et dépendances cryptographiques.
• Prioriser les secrets qui doivent rester protégés longtemps.
• Demander aux fournisseurs leur trajectoire de mise à jour et les preuves disponibles.
• Tester les solutions hybrides pertinentes selon les recommandations ANSSI et les contraintes d’interopérabilité.

Relier les obligations au périmètre réel

NIS2 et le Data Act répondent à des questions différentes pour une PME : la première impose des exigences de cybersécurité aux entités entrant dans son champ, tandis que le second encadre notamment la possibilité de changer de fournisseur de traitement de données [11][12].

• Champ NIS2 : qualifier le secteur, la taille, les exceptions et la transposition nationale applicable avant de conclure à un assujettissement.
• Chaîne de fournisseurs : distinguer l’obligation légale directe des exigences de sécurité demandées par un client dans son contrat.
• Changement de cloud : examiner les clauses d’export et de transition ; le Data Act prévoit la suppression des frais de changement, y compris de sortie des données, à partir du 12 janvier 2027.
• Preuve opérationnelle : effectuer un export et une reprise testés, car un droit contractuel ne démontre pas à lui seul la portabilité d’une application.

Chapitre 5 : FinOps, TCO et retour sur investissement

Le coût unitaire des modèles baisse souvent alors que la facture totale augmente avec les volumes, les chaînes agentiques et les intégrations ; le pilotage doit donc porter sur le coût par résultat métier fiable plutôt que sur le seul prix du million de tokens.

• Mesurer les volumes par équipe, cas d’usage, modèle et environnement.
• Acheminer chaque tâche vers le modèle le moins coûteux qui atteint le seuil de qualité requis.
• Mettre en cache seulement les contenus stables, avec une politique d’invalidation et de confidentialité.
• Fixer des plafonds, alertes, quotas et procédures d’exception dans une gateway ou une couche de contrôle réellement capable de les appliquer.
• Revoir chaque mois coût, qualité, latence, adoption et impact dans la même décision.

Le TCO additionne tous les coûts nécessaires à l’obtention et au maintien du résultat sur la période, y compris ceux qui restent souvent hors du budget logiciel.

• Licences, appels de modèles, stockage, réseau et outils d’observabilité.
• Intégration, nettoyage des données, évaluations, sécurité et conformité.
• Formation, conduite du changement, support et temps des experts métier.
• Exploitation, incidents, dépendance fournisseur, réversibilité et renouvellement du matériel.

Le ROI d’une période se définit par (bénéfices attribuables − coûts totaux) / coûts totaux, avec des bénéfices convertis selon leur nature et sans compter deux fois la même heure libérée.

• Économies de trésorerie : dépenses réellement évitées, nettes des effets de déplacement.
• Capacité libérée : heures disponibles valorisées séparément tant qu’elles ne réduisent pas une dépense ou ne produisent pas une marge démontrable.
• Croissance : marge incrémentale attribuable, pas chiffre d’affaires brut ni pipeline.
• Risque : variation documentée de perte attendue, avec probabilité et impact explicités.
• Sensibilité : scénario bas, central et haut sur l’adoption, la qualité, le volume et les coûts.

Une couche de contrôle qui applique les décisions

La maîtrise budgétaire exige une couche capable d’autoriser ou de refuser les appels avant que la dépense soit engagée, puis de rapprocher l’estimation du coût réellement facturé ; un tableau de bord d’observabilité fournit des informations utiles sans remplir nécessairement cette fonction de contrôle.

• Admission : authentifier l’appelant, vérifier le projet et réserver un budget estimé avant d’envoyer la requête.
• Exécution : limiter le nombre d’étapes, la durée, les nouvelles tentatives et les outils accessibles au processus.
• Rapprochement : remplacer l’estimation par le coût observé et traiter les écarts, y compris les appels simultanés.
• Exception : prévoir une augmentation approuvée ou un service dégradé lorsque le plafond est atteint.

La revue mensuelle devient utile lorsqu’elle relie chaque écart à une action attribuée, car une baisse du prix unitaire peut masquer un volume inutile, une dégradation de qualité ou une dépendance opérationnelle plus coûteuse.

• Volume : séparer la croissance attendue des doublons, boucles et requêtes inutilisées.
• Qualité : suivre les reprises et refus, avec une comparaison stable entre versions.
• Économie : examiner le coût complet par résultat accepté et l’utilisation effective de la capacité libérée.
• Arbitrage : désigner la personne qui conserve, ajuste, étend ou arrête l’usage, avec une échéance et une mesure attendue.

Exemple de calcul : capacité libérée et ROI

Cet exemple entièrement illustratif montre pourquoi une économie de temps ne suffit pas à annoncer un ROI financier : le même pilote peut libérer une capacité importante tout en présentant un résultat économique négatif sur sa première année.

• Périmètre : 2 000 dossiers traités dans l’année, avec vingt minutes de travail net économisées par dossier, relecture et corrections incluses.
• Capacité : 666,7 heures libérées, soit environ 26 667 € de capacité valorisée à 40 € par heure ; ce montant reste séparé des bénéfices financiers ci-dessous.
• Bénéfices réalisés : 18 000 € de prestations évitées et 10 000 € de marge additionnelle attribuable, sans recouvrement entre ces deux postes.
• Coûts complets : 30 000 € sur la même année, couvrant mise en place, exploitation et accompagnement.

La décision dépend ensuite des hypothèses qui peuvent changer le résultat, en conservant la même période et en évitant de compter deux fois une heure qui contribue déjà à une prestation évitée ou à la marge additionnelle.

• Tester une adoption plus faible et des reprises plus fréquentes.
• Distinguer les coûts de démarrage des coûts récurrents avant de projeter l’année suivante.
• Comparer le coût d’une extension à son bénéfice marginal, plutôt que de prolonger mécaniquement le ROI moyen.
• Fixer le seuil et la date de réexamen avec le responsable métier et la finance.

Utiliser ISO/IEC 42001 à bon escient

ISO/IEC 42001 fournit un cadre de management de l’IA pour organiser les responsabilités, les risques et l’amélioration continue ; son utilité dépend du périmètre couvert et des pratiques effectivement mises en œuvre dans l’entreprise [7].

• Définir les activités et systèmes couverts avant de construire la documentation.
• Relier les politiques aux décisions, contrôles et preuves de fonctionnement.
• Choisir une éventuelle certification selon les besoins commerciaux et de gouvernance.
• Examiner séparément les obligations légales applicables et la performance de chaque système.

Chapitre 6 : une méthodologie en cinq phases

La transformation avance par preuves successives : chaque phase réduit une incertitude précise et se termine par une décision de poursuivre, redessiner ou arrêter avant d’engager davantage de données, d’intégrations et de changement humain.

• 1. Diagnostic : inventorier usages, processus, données, risques, compétences et coûts ; sortie, niveau par dimension et lacunes prioritaires.
• 2. Cadrage : sélectionner un petit portefeuille par valeur, faisabilité et risque ; sortie, propriétaire, baseline, seuils et protocole d’évaluation.
• 3. Fondations : préparer corpus, droits, architecture, sécurité, formation et procédure de repli ; sortie, environnement prêt à tester.
• 4. Pilote : tester avec de vrais utilisateurs et des cas représentatifs ; sortie, décision documentée fondée sur qualité, adoption, coût, délai et incidents.
• 5. Consolidation : industrialiser, journaliser, versionner, réviser et étendre ; sortie, revue d’exploitation et portefeuille actualisé.

Commander l’IA par le contexte

La qualité d’un système dépend davantage du contexte, des outils, des exemples, des limites et de l’évaluation que d’une formule de prompt isolée ; « commander l’IA » signifie donc concevoir un environnement d’exécution contrôlé.

• Définir l’objectif, le format attendu et les critères de réussite.
• Fournir uniquement les sources autorisées, à jour et nécessaires.
• Encadrer les outils accessibles, les actions interdites et les validations humaines.
• Tester des cas normaux, limites et adverses avant chaque changement important.
• Conserver version, sources, résultat, validation et incident pour apprendre.

Chapitre 7 : INDUSTEC, protocole d’évaluation d’un assistant de devis

L’exemple illustratif INDUSTEC sert ici à montrer comment évaluer un assistant de devis sans réduire la preuve à un temps déclaré : le protocole relie périmètre, baseline, qualité, adoption, capacité et marge avant de calculer un retour.

• Délimiter le processus de devis : déclencheur, variantes, intervenants, reprises et validation finale.
• Mesurer avant déploiement un échantillon représentatif : temps actif, délai de bout en bout, taux de correction, marge et taux de transformation.
• Concevoir l’assistance autour des sources autorisées, des règles de prix, des exceptions et d’une validation commerciale explicite.
• Suivre séparément adoption, temps, qualité, incidents, capacité libérée et marge incrémentale.
• Réconcilier les unités, la période et la population avant toute publication de gain ou de ROI.

L’enseignement méthodologique reste valide sans chiffre spectaculaire : un cas de devis peut être pertinent si l’entreprise améliore à la fois le délai et la qualité, mais le bénéfice doit être établi sur le périmètre réel et comparé au coût complet du dispositif.

• Une heure déclarée « gagnée » n’est pas automatiquement une heure de trésorerie économisée.
• Un devis produit plus vite ne crée du revenu que si la capacité est utilisée et si la marge additionnelle est attribuable.
• Un taux de transformation doit être comparé sur des affaires comparables et une période suffisante.
• La décision d’investissement se fonde sur la base mesurée, les coûts complets et la sensibilité des hypothèses propres à l’entreprise.

Chapitre 8 : feuille de route sur douze mois

Une année de travail peut installer une boucle de décision et quelques usages fiables, à condition d’adapter le rythme au risque et à la dette de données plutôt que de promettre un niveau de maturité identique à toutes les entreprises.

• Trimestre 1 — voir et choisir : inventaire, diagnostic, règle d’usage, baselines et portefeuille priorisé.
• Trimestre 2 — préparer et tester : données minimales, architecture, formation, contrôles et premier pilote.
• Trimestre 3 — décider et exploiter : passage en production conditionnel, support, mesure et revue mensuelle.
• Trimestre 4 — consolider et étendre : standard commun, audit ciblé, réversibilité testée et feuille de route suivante.

La gouvernance de la feuille de route tient dans un tableau de bord court qui relie chaque usage à une décision, évitant que la collection d’indicateurs ne remplace la responsabilité.

• Valeur : résultat métier net et hypothèse d’attribution.
• Usage : utilisateurs actifs et fréquence sur la population visée.
• Qualité : réussite sur le jeu d’évaluation et reprises humaines.
• Risque : incidents, exceptions, données et actions bloquées.
• Coût : TCO engagé, coût par résultat et prévision.
• Décision : poursuivre, corriger, étendre ou arrêter, avec un propriétaire et une date.

Chapitre 9 : décider du prochain palier

La maturité IA sert à choisir le prochain investissement que l’organisation peut absorber, prouver et gouverner tout en gardant la maîtrise de ses données, de ses coûts et de ses décisions.

• Commencer par les preuves manquantes du niveau actuel.
• Cadrer un cas où le point de départ et le résultat sont mesurables.
• Installer les responsabilités et la procédure d’arrêt avant l’autonomie.
• Comparer les options d’infrastructure sur le TCO, le risque et la réversibilité.
• Étendre seulement après une revue commune de la valeur, de l’usage, de la qualité et du risque.

Du diagnostic à l’industrialisation

Ce livre blanc répond à « où en sommes-nous ? » ; le volume suivant, Du POC à l’industrialisation, traite la conduite du changement, l’AgentOps et la mise en production à l’échelle.

• Lire le livre blanc n°2 en ligne.
• Voir la collection des livres blancs.

Audit de maturité IA Junyr

L’offre actuelle de Junyr.eu est un audit gratuit de trente minutes qui donne une position, le principal blocage vers le niveau suivant et le premier chantier pertinent, puis transmet un livrable d’une page [6].

• Réalisé en visioconférence par un Transformateur IA du réseau avec une trame commune.
• Sans engagement et sans obligation de poursuivre par une mission ou par Junyr Suite.
• Orienté vers une décision initiale, sans promesse de certification, de conformité ou de feuille de route complète.
• Réserver l’audit de maturité IA.

Sources et limites

Les sources suivantes étayent les affirmations externes conservées ; les observations de méthode sont présentées comme des recommandations, et les liens réglementaires doivent être relus lors de chaque décision à enjeu.

• [1] DGE / France Num, Baromètre France Num 2025, 11 021 entreprises : 26 % déclarent utiliser une solution d’IA. Consulter la source
• [2] Ministère de l’Économie, Osez l’IA, objectif 2030 : 80 % des PME et ETI utilisant l’IA. Consulter la source
• [3] KPMG, Global AI Pulse, 31 mars 2026, n = 2 110 dirigeants, entreprises d’au moins 100 M$ de chiffre d’affaires : 64 % rapportent des résultats significatifs et 11 % appartiennent au groupe « AI leaders ». Consulter la source
• [4] Union européenne, règlement (UE) 2024/1689 établissant l’AI Act. Consulter la source
• [5] Union européenne, règlement (UE) 2026/1744 modifiant l’AI Act, notamment l’article 4 et le calendrier des systèmes à haut risque. Consulter la source
• [6] Junyr.eu, offre d’audit de maturité IA, consultée le 6 septembre 2026. Consulter la source
• [7] ISO, ISO/IEC 42001:2023, système de management de l’intelligence artificielle. Consulter la source
• [8] ANSSI, recommandations de sécurité et publications sur la cryptographie post-quantique. Consulter la source
• [9] U.S. Department of Justice, The Purpose and Impact of the CLOUD Act, April 2019. Consulter la source
• [10] Hugging Face, Transformers: Quantization overview. Consulter la source
• [11] European Commission, NIS2 Directive: securing network and information systems. Consulter la source
• [12] European Commission, Data Act explained. Consulter la source Première publication le 23 mai 2026 ; révision du 6 septembre 2026, version 2.4.