IA dans les PME : des usages quotidiens aux gains mesurables

Vous dirigez une PME : quels usages de l’IA peuvent améliorer votre performance commerciale, et comment en vérifier les gains ? Cet article explique comment structurer votre gouvernance IA, définir les droits d’accès aux données et répartir les responsabilités, du pilotage à la mise en production. Vous y trouverez les indicateurs pour mesurer les délais de réponse, la conversion et le coût complet, afin d’arbitrer vos investissements sur des résultats vérifiés.

Pourquoi l’adoption de l’IA ne suffit-elle pas à démontrer sa valeur ?

Que va permettre cet article ?

Selon l’Insee, 18 % des entreprises françaises de dix salariés ou plus utilisaient au moins une technologie d’intelligence artificielle en 2025. Cette proportion atteignait 31 % entre 50 et 249 salariés et 58 % à partir de 250 salariés. Publiée en juillet 2026, l’étude porte sur les secteurs principalement marchands, hors agriculture, finance et assurance. [1]

Ces chiffres décrivent une adoption utilisateur. Ils ne mesurent ni un retour sur investissement (ROI), ni la qualité des décisions prises avec l’intelligence artificielle. Une entreprise peut avoir équipé ses collaborateurs et rester incapable d’identifier les tâches effectivement améliorées.

Le nombre de comptes activés et la fréquence des connexions renseignent sur l’utilisation d’un outil. Pour décider d’un investissement, il faut aussi regarder ce qui se passe après la réponse : vérification, correction, saisie dans un autre logiciel, traitement des exceptions. C’est là que le gain annoncé peut se confirmer ou disparaître.

Un gain de temps individuel devient-il un résultat pour l’entreprise ?

Une étude publiée en 2025 dans The Quarterly Journal of Economics analyse le déploiement progressif d’un assistant génératif auprès de 5 172 agents de support client. Les chercheurs observent une hausse moyenne de 15 % du nombre de problèmes résolus par heure, avec des effets très différents selon l’expérience utlisateur et les compétences des agents. [2]

Ce résultat concerne un dispositif et un métier précis. Il ne permet pas de promettre le même gain à une direction commerciale ou à un service achats. Son intérêt est aussi méthodologique : l’effet est observé sur une activité, avec un indicateur de production identifiable.

Pour une entreprise, la question devient donc : quelle opération veut-on améliorer, et comment saura-t-on qu’elle l’est ? Des minutes libérées peuvent apporter de la capacité supplémentaire, réduire un délai ou améliorer le service. Elles ne constituent une économie comptable que si les dépenses diminuent effectivement. Il faut nommer le bénéfice attendu avant de le chiffrer.

Quels bénéfices commerciaux faut-il chercher à mesurer ?

Des réponses plus rapides peuvent-elles améliorer le suivi des demandes ?

Un assistant IA pour votre PME peut aider à retrouver une information produit, rapprocher les éléments d’un dossier ou préparer un devis. Le bénéfice à vérifier est la réduction du délai jusqu’à une réponse utilisable par le client, en comptant les vérifications et les corrections nécessaires.

Nous recommandons de suivre le délai médian de réponse, la part des demandes traitées dans le délai convenu et le nombre de dossiers en attente. Si le temps libéré permet de traiter davantage de demandes qualifiées à effectif constant, l’entreprise dispose d’une capacité commerciale supplémentaire. Cela ne prouve pas encore qu’elle a réalisé plus de ventes : la conversion doit être observée séparément.

Pour organiser ce suivi, notre article sur le rôle d’un CRM dans le pilotage d’une équipe commerciale présente les liens entre centralisation des informations, suivi des opportunités et analyse des performances. Ces données constituent un point de départ pour comparer le processus avec et sans assistance IA.

Comment vérifier un effet sur la conversion ?

Sur un parcours de demande de devis, le taux de conversion peut être défini comme la part des devis émis qui aboutissent à une commande, pour une population et une période fixées. Sur un portail de commande, il faut préciser ce qui constitue le début et la fin du parcours observé.

Pour mesurer l’effet d’un nouvel usage IA pour votre PME, nous recommandons de comparer des groupes ou des périodes suffisamment comparables. Il faut tenir compte des changements de prix, de la qualité des demandes entrantes et du cycle de vente. Une commande signée plusieurs mois après un devis ne peut pas être évaluée à partir d’un test de quelques jours.

Le suivi doit aussi distinguer les opportunités perdues de celles qui sont encore ouvertes. Une comparaison utile peut porter sur des devis émis au cours d’une même période, avec un recul identique avant le calcul. Si les dossiers assistés par IA sont plus simples ou confiés aux commerciaux les plus expérimentés, un meilleur taux de conversion ne suffit pas à attribuer l’écart à l’outil.

Dans une organisation équipée de HubSpot, cette mesure suppose des étapes de vente et des données de suivi cohérentes. Le travail de conception et d’intégration de HubSpot CRM permet de cadrer le parcours, les informations à enregistrer et les échanges avec les autres outils. L’enjeu est de pouvoir relier une demande, un devis et son issue, avec une définition commune des indicateurs.

Cette lecture du parcours rejoint la conception de plateformes e-commerce B2B intégrées au système d’information : relier les informations produits, les conditions commerciales et les commandes pour pouvoir suivre ce qui facilite ou freine l’achat.

Quels gains restent une fois les coûts et les corrections pris en compte ?

Un volume de ventes plus élevé peut s’accompagner de remises plus importantes, d’erreurs de tarification ou de davantage de reprises. La contribution commerciale doit donc être examinée avec la marge et le coût de traitement, selon les définitions retenues par l’entreprise.

Nous recommandons de suivre le coût par dossier correctement traité et, si les données le permettent, par commande obtenue. Cette lecture doit inclure les outils digitaux, l’intégration, la maintenance et le temps de contrôle. Le temps gagné, l’économie de dépenses et la marge supplémentaire sont des bénéfices distincts : les additionner sans examiner leurs liens risquerait de compter deux fois le même effet.

La gouvernance ne garantit aucun de ces gains. Elle donne aux équipes les moyens de les vérifier, de corriger un usage insuffisant et de décider si son développement se justifie.

Pour l’évaluation économique, nous recommandons de fixer un même horizon de calcul pour les coûts et les bénéfices. Un scénario prudent distingue les dépenses initiales d’intégration, les frais récurrents et les gains effectivement observés. La capacité de travail libérée peut être suivie en heures, sa valorisation monétaire doit préciser ce qui en sera fait. Une économie de dépenses et une marge additionnelle peuvent ensuite être retenues lorsqu’elles sont justifiées, sans compter à nouveau les mêmes heures comme un troisième gain.

 

Comment organiser la gouvernance autour des objectifs commerciaux ?

Quel problème métier mérite d’être traité ?

« Nous voulons un assistant IA » décrit une solution envisagée. « Nos équipes passent trop de temps à rechercher les conditions applicables à une commande » décrit un problème que l’on peut examiner.

Notre recommandation est de commencer par le parcours complet : d’où vient la demande, quelles informations sont nécessaires, qui les valide et dans quel outil le résultat doit-il être enregistré ? Cette observation peut révéler qu’un problème attribué au manque d’IA vient d’un référentiel incomplet ou d’une procédure devenue illisible.

La démarche rejoint celle des applications métier, intranets et extranets connectés au système d’information : comprendre les flux et les responsabilités avant de développer une nouvelle fonctionnalité. Une automatisation classique ou une meilleure recherche documentaire peut parfois suffire.

Comment comparer les projets avant d’engager un budget ?

Nous recommandons de comparer quatre éléments : l’effet attendu sur l’activité, la faisabilité avec les données disponibles, le coût complet et les conséquences possibles d’une erreur. La fréquence d’une tâche aide à estimer le gain potentiel ; la fiabilité des sources et les connexions nécessaires déterminent une partie de l’effort d’intégration.

Par exemple, un assistant documentaire peut traiter un volume important de recherches tout en laissant la décision au collaborateur. Une fonction qui modifie automatiquement des conditions commerciales nécessite d’autres contrôles. Le premier n’est pas systématiquement le meilleur investissement : il faut rapprocher le bénéfice attendu de l’effort, du risque et des priorités de l’entreprise.

Une comparaison explicite permet de distinguer les projets à tester, ceux qui nécessitent d’abord une remise en ordre des données et ceux à différer. Un score unique ne doit pas masquer un blocage de sécurité ou une absence de besoin métier.

Qui peut autoriser le test, le déploiement et l’arrêt ?

La gouvernance de l’IA pour votre PME désigne ici l’organisation des décisions, des responsabilités et des contrôles qui encadrent ses usages tout au long de leur exploitation. Elle doit permettre de répondre à une question très pratique : qui décide, sur quels éléments et avec quelles limites ?

Pour un premier projet, nous recommandons de nommer un responsable métier du résultat, un responsable technique de l’exploitation et les interlocuteurs à consulter selon les données et les risques. Le responsable métier définit ce qu’est une réponse acceptable. L’équipe technique précise ce que le système peut réellement garantir et comment il sera maintenu.

La CNIL recommande notamment de partir d’un besoin concret, d’encadrer les usages, de former les utilisateurs et d’associer dès le départ les parties prenantes pertinentes, dont les métiers, la DSI, le RSSI et le délégué à la protection des données. [3]

Tout ne nécessite pas la même procédure. Préparer un brouillon interne et modifier une donnée de facturation n’exposent pas l’entreprise aux mêmes conséquences. Les validations doivent dépendre de l’usage, de ses destinataires, des informations traitées et des actions possibles.

Quel mandat confier à un comité de gouvernance IA ?

Lorsque plusieurs directions développent leurs usages, nous recommandons de confier les arbitrages communs à une instance réunissant les métiers, la DSI et les fonctions de contrôle concernées. Ce comité de gouvernance IA, parfois appelé AI Council, doit pouvoir autoriser un périmètre, engager les moyens nécessaires et demander sa révision. Sa composition dépend des décisions à prendre : sa responsabilité doit être explicite.

Un responsable de projet ne peut pas, seul, arbitrer l’accès à des données partagées, la mobilisation d’une équipe technique déjà engagée ailleurs et le niveau de risque accepté par l’entreprise. Le comité doit traiter ces dépendances, fixer les priorités et résoudre les désaccords. Les décisions courantes restent au niveau des équipes qui exploitent le service, dans les limites approuvées.

Nous recommandons de préciser le mandat par écrit : décisions réservées à la direction, délégations, conditions de nouvelle validation et personnes à saisir en cas d’urgence. Il faut aussi réserver du temps pour examiner les demandes, réaliser les tests et suivre les écarts. Une instance sans capacité de décision ni moyens d’instruction risque de devenir une réunion supplémentaire.

Comment piloter l’ensemble des projets sans disperser les ressources ?

Le pilotage d’un portefeuille consiste à regarder les projets ensemble : objectifs poursuivis, données utilisées, coûts, personnes mobilisées et dépendances techniques. Deux usages prometteurs peuvent se concurrencer pour la même compétence ou dépendre du même chantier de qualité des données. À l’inverse, un connecteur ou un référentiel préparé pour l’un peut servir à l’autre.

Nous recommandons de tenir une vue commune des usages en test, en production et à l’arrêt, y compris les fonctionnalités IA intégrées à des logiciels déjà achetés. Elle permet de repérer les abonnements redondants, de mutualiser un travail utile et de différer les projets dont les prérequis ne sont pas réunis. Le budget doit couvrir les moyens de contrôle et l’exploitation future, au-delà de la démonstration initiale.

Pour chaque décision de financement, la direction doit pouvoir comprendre ce que le projet IA doit améliorer, quelles preuves manquent encore et quelle autre utilisation des mêmes ressources serait possible. Cette comparaison rend les priorités discutables et révisables, plutôt que dépendantes de la dernière démonstration présentée.

Le registre doit identifier une version du service et ses dépendances : modèle, configuration, sources documentaires et connecteurs. Ce repérage permet de distinguer un changement d’usage d’une simple évolution technique et de savoir quels tests doivent être rejoués. La décision approuve ainsi un périmètre identifiable, que l’équipe peut comparer à ce qui fonctionne réellement en production.

Que doit contenir la fiche de décision d’un cas d’usage ?

Un document court peut réunir les éléments nécessaires à l’arbitrage : problème traité, utilisateurs concernés, responsable métier, données accessibles, actions autorisées, budget du test et date de réexamen. Il doit aussi fixer les critères de réussite, les situations qui imposent une intervention humaine et les motifs d’arrêt. Pour un usage commercial, préciser l’indicateur retenu et sa définition : délai de réponse, devis transformés en commandes ou coût de traitement, par exemple.

Cette fiche évite qu’un prototype change progressivement de fonction sans nouvelle décision. Un assistant autorisé à rechercher des informations ne doit pas devenir, au fil des évolutions, un outil qui engage une dépense sans révision de son périmètre.

Quelles règles faut-il rendre applicables au quotidien ?

Quels usages de l’IA échappent encore au contrôle de votre entreprise ?

Un commercial utilise son compte personnel pour résumer un échange client. Un collaborateur ajoute une extension pour préparer ses réponses. Une équipe active une fonction IA dans un logiciel déjà installé. Ces initiatives peuvent rester absentes de l’inventaire technique et des achats suivis par l’entreprise. Le sujet concerne alors des usages réels dont les données, les accès et les conditions d’exploitation n’ont pas été examinés.

Ces pratiques peuvent répondre à une difficulté que les outils autorisés résolvent mal : retrouver une information, traiter un document ou réduire le temps passé à rédiger. Si les solutions disponibles sont inadaptées ou leur validation trop difficile à obtenir, les équipes peuvent chercher une autre voie. Recenser les outils sans comprendre les tâches concernées ne suffit donc pas à construire une réponse durable.

Le premier enjeu porte sur les informations transmises. Un document peut contenir des coordonnées, des tarifs négociés ou des clauses confidentielles. Avant d’autoriser son traitement, il faut examiner le service exact, son compte d’utilisation, les données conservées et leur éventuelle réutilisation. La CNIL recommande de définir les usages autorisés et interdits, de vérifier les conditions de réutilisation par le prestataire et de former les utilisateurs. [3] Une même marque peut proposer des offres aux conditions différentes ; le nom de l’outil ne suffit pas à valider l’usage.

Le coût dépasse également l’abonnement visible. Des achats dispersés peuvent financer plusieurs fonctions similaires, tandis que le temps de vérification et de correction reste réparti entre les équipes. Un document transmis au mauvais service peut aussi imposer une analyse d’incident et des mesures de remédiation. Ces dépenses et ces risques doivent être examinés avec les gains annoncés, sans attendre qu’un problème les rende visibles.

Nous recommandons un recensement fondé sur les tâches, les outils et les flux : quel besoin est traité, avec quel compte, quelles informations et quelles connexions ? Les échanges avec les métiers et l’examen des achats permettent de commencer cette cartographie. Pour chaque usage, une personne doit ensuite décider de son maintien, de son adaptation ou de son remplacement. La réponse doit préciser ce qui est permis immédiatement, ce qui nécessite une validation et comment obtenir cette validation.

L’apport de conception consiste à rendre la solution encadrée praticable au quotidien. Pour préparer une réponse client, un assistant intégré à l’application métier peut recevoir uniquement les informations nécessaires au dossier, respecter les permissions existantes et présenter un brouillon à valider. Les conditions du service et les contrôles restent à vérifier. L’entreprise répond ainsi au besoin initial tout en organisant les accès, la traçabilité et la reprise du travail si l’outil devient indisponible.

Quelle différence entre une politique d’usage et une procédure ?

Une politique d’usage fixe les règles communes : outils approuvés, catégories de données admises, actions interdites et responsabilités. Une procédure décrit leur application dans une situation précise : comment demander un accès, faire valider un nouveau connecteur ou signaler une information envoyée au mauvais service.

Nous recommandons d’illustrer ces règles avec des documents réellement manipulés par les équipes. Un commercial doit pouvoir déterminer si un devis nominatif, une clause contractuelle ou une liste de prospects peut être transmis à un service donné. La réponse dépend de l’offre utilisée, des données et du contexte : elle doit être assez précise pour permettre une décision sans interprétation improvisée.

Les exceptions demandent également un circuit explicite. Qui peut les accepter, pour quelle durée et avec quelles mesures supplémentaires ? Une autorisation temporaire doit avoir une date de réexamen et un responsable. Sans cela, l’exception peut devenir un usage durable que personne ne réévalue.

Que faut-il examiner avant d’autoriser un outil ou un fournisseur ?

L’évaluation doit porter sur le service exact : données transmises, conservation, réutilisation éventuelle, sous-traitants, modalités d’accès, conditions de sortie et traitement des incidents. La CNIL recommande notamment de vérifier dans quelle mesure le prestataire peut réutiliser les données fournies et d’adapter les usages en conséquence. [3]

Nous recommandons de rapprocher les réponses contractuelles du fonctionnement technique. Une possibilité de suppression annoncée doit être examinée pour les documents, les historiques et les copies concernées. Une restriction sur les données doit aussi être cohérente avec les connecteurs, les journaux et les outils de support. L’achat du logiciel et son intégration doivent donc être instruits ensemble.

Une certification ou une documentation de sécurité constitue un élément d’examen. Il reste à vérifier le périmètre couvert et les responsabilités qui reviennent au client. Le NIST AI RMF traite explicitement des risques liés aux logiciels, aux données et aux acteurs tiers, ainsi que des dispositions de continuité associées. [9]

L’examen fournisseur doit également prévoir les changements après signature : modification des conditions d’utilisation, évolution du service et retrait d’un modèle. Il faut identifier qui reçoit ces informations et qui en examine les conséquences. Pour les données ou contenus fournis par des tiers, les droits d’usage et les licences doivent être examinés selon les traitements envisagés. Une autorisation donnée pour consulter un document ne doit pas être présumée couvrir tous les usages possibles de son contenu.

Cette évaluation rejoint la question de la réversibilité : quels éléments faudra-t-il modifier si votre PME change de fournisseur ? Notre analyse des risques de dépendance technologique à OpenAI, Claude et aux autres fournisseurs d’IA détaille le rôle des modèles, des connecteurs et des tests de substitution dans cette capacité de sortie.

Comment évaluer les risques sans appliquer le même contrôle à tous les usages ?

Nous recommandons de partir de ce que le système peut faire et de ce qu’une erreur peut provoquer. Qui reçoit la réponse ? Peut-elle engager l’entreprise ? Le système peut-il écrire dans un logiciel ? Quelles personnes pourraient être affectées ? Cette analyse détermine les contrôles utiles, puis les exigences réglementaires à examiner.

Le registre des risques doit relier chaque scénario à une mesure, à un responsable et à une décision sur le risque restant. Par exemple, une proposition de remise erronée peut être encadrée par un plafond appliqué dans le logiciel commercial et une validation au-delà de ce seuil. Il faut ensuite vérifier que ce contrôle fonctionne, y compris lorsque l’information fournie au modèle est incomplète ou contradictoire.

L’évaluation doit aussi rechercher les erreurs récurrentes selon les catégories de demandes ou de clients. Un taux moyen satisfaisant peut masquer une mauvaise prise en charge d’un segment. Nous recommandons d’examiner les effets sur les personnes et l’équité du traitement lorsqu’un système classe, recommande ou influence une décision.

Comment articuler gouvernance, ISO 42001 et AI Act ?

À quoi sert ISO/IEC 42001 dans une démarche de gouvernance ?

Publiée en décembre 2023, ISO/IEC 42001 définit les exigences d’un système de management de l’intelligence artificielle. Elle organise la mise en place, le maintien et l’amélioration continue de ce système au sein d’une organisation. L’ISO présente une démarche fondée sur le cycle planifier, mettre en œuvre, vérifier et améliorer, applicable aux organisations qui fournissent ou utilisent des produits et services IA. [6]

Pour une PME, l’intérêt est de disposer d’un cadre pour relier politique, responsabilités, risques et vérifications dans la durée. La question d’une certification doit être examinée selon les objectifs et les exigences des clients. Elle porte sur un périmètre défini et ne dispense ni d’évaluer chaque usage ni d’examiner les obligations légales applicables.

Quelles questions l’AI Act ajoute-t-il au cadrage des projets ?

Le règlement européen sur l’IA impose d’examiner la finalité du système, sa qualification et le rôle de l’entreprise dans sa conception ou son utilisation. Tous les usages ne relèvent pas du même niveau d’exigence. La qualification de système à haut risque suit les critères de l’article 6 ; pour les déployeurs concernés, l’article 26 prévoit notamment des mesures d’utilisation appropriée, une supervision humaine et un suivi du fonctionnement. [10]

Le calendrier doit être vérifié pour le système étudié. Dans son communiqué du 29 juin 2026 sur la simplification de l’AI Act, le Conseil de l’Union européenne annonce deux échéances selon les catégories de systèmes à haut risque : le 2 décembre 2027 et le 2 août 2028, cette seconde date visant des systèmes intégrés à des produits. Le périmètre exact doit être examiné dans les textes applicables. Ces échéances ne constituent pas un report général de toutes les règles relatives à l’IA. [7]

L’organisation doit donc conserver, pour chaque usage, une analyse de son périmètre réglementaire et des actions à mener. Lorsqu’il y a des données personnelles, l’examen du RGPD reste nécessaire. La gouvernance permet de réunir les informations utiles et d’associer les interlocuteurs compétents ; elle ne se substitue pas à l’analyse juridique du cas concret.

Comment former les équipes selon leurs responsabilités ?

L’article 4 de l’AI Act prévoit des mesures de développement des compétences en IA adaptées aux connaissances des personnes et au contexte d’utilisation. Le texte consolidé présenté par le service officiel de la Commission précise que cette obligation ne demande pas de garantir un niveau individuel déterminé. [10]

Nous recommandons une formation liée aux tâches : reconnaître une réponse plausible mais inexacte pour les utilisateurs, examiner les exceptions pour les responsables métier, contrôler les permissions et les évolutions pour l’équipe technique. Il faut prévoir du temps pour pratiquer, poser des questions et signaler les difficultés rencontrées. La capacité à appliquer les règles doit être observée dans les parcours réels, au-delà d’une simple participation à une session.

Comment intégrer les règles de gouvernance dans les outils métier ?

Quelles données le système doit-il pouvoir consulter ?

Un assistant chargé de préparer une réponse commerciale peut avoir besoin du catalogue, des conditions contractuelles et de certaines données de commande. Cela ne justifie pas l’ouverture de toutes les informations du CRM ou de l’ERP.

Nous recommandons de cartographier les sources utiles, leur propriétaire, leur fréquence de mise à jour et les droits d’accès applicables. Une réponse fondée sur un tarif périmé peut être parfaitement rédigée et commercialement fausse. La qualité de la sortie dépend aussi de l’information que le système est autorisé à retrouver.

Il faut préciser quel système fait autorité pour chaque information. Les caractéristiques d’un produit peuvent venir du PIM, ses médias du DAM et ses conditions de vente de l’ERP. La gouvernance et l’intégration des référentiels PIM et DAM contribuent à clarifier cette circulation. Le connecteur doit transmettre la référence et la version utiles ; si deux sources se contredisent ou si la mise à jour est trop ancienne pour l’usage prévu, le système doit pouvoir signaler cette limite plutôt que choisir silencieusement une réponse.

L’expérience de Kwantic dans l’intégration des plateformes métier donne un point d’appui concret à cette réflexion. Pour Dimaco et HydroClean, la plateforme e-commerce B2B développée sur Sylius est connectée à Sage pour synchroniser notamment les produits, stocks, tarifs et documents de facturation. Cette réalisation concerne l’intégration du système d’information, sans constituer un cas de déploiement IA. Elle illustre un préalable utile : identifier le référentiel qui fait autorité avant de diffuser l’information dans un autre outil.

Quelles actions doivent rester soumises à validation ?

Lire une commande, proposer sa modification et enregistrer cette modification sont trois niveaux d’autorisation distincts. Pour chaque opération, il faut préciser les droits nécessaires, les contrôles à effectuer et le responsable de la validation.

Ces permissions doivent être appliquées par les applications et les services connectés. Une consigne écrite dans le prompt ne remplace pas un contrôle d’accès. Les recommandations de l’ANSSI sur la sécurité des systèmes d’IA générative abordent notamment l’encadrement des interactions avec d’autres applications et la maîtrise des accès à privilèges. [4]

La validation humaine doit également être utilisable. La personne qui approuve doit voir les informations pertinentes, les changements proposés et les éléments à vérifier. Si elle doit reconstituer tout le dossier pour comprendre la proposition, la charge de contrôle peut absorber le gain attendu.

Ce travail relève aussi de la conception UX des parcours métier : rendre la décision compréhensible, permettre la correction et organiser le traitement des exceptions.

Comment appliquer ces contrôles dans un ERP comme Odoo ?

La documentation d’Odoo distingue les droits d’accès aux modèles de données et les règles qui s’appliquent aux enregistrements. Les premiers encadrent les opérations possibles ; les secondes précisent les conditions d’accès aux dossiers concernés. [11] Dans un projet d’intégration et de gouvernance d’Odoo, le raccordement d’un usage IA doit donc être examiné avec les comptes, groupes et règles existants. Un compte technique doté de droits très larges ne devient pas restreint parce que le prompt demande de ne consulter que certains dossiers.

Pour une opération en écriture, nous recommandons de contrôler côté application les paramètres reçus, l’état du dossier et le droit de l’acteur qui engage l’action. Il faut aussi traiter les nouvelles tentatives après un délai d’attente : une requête rejouée ne doit pas créer deux commandes ou envoyer deux fois le même message. Selon l’architecture, cela peut passer par un identifiant d’opération et une vérification des actions déjà exécutées. La conception doit préciser les cas où l’action peut être annulée et ceux qui nécessitent une correction métier.

Ces précautions prolongent les questions abordées dans notre guide sur l’intégration d’un ERP aux outils digitaux : définir les flux et les responsabilités de chaque système avant de multiplier les connexions.

Comment résister aux instructions malveillantes présentes dans les documents ?

Une instruction adressée au modèle peut être dissimulée dans une page ou un document qu’il consulte. Cette attaque, appelée injection indirecte de prompt, cherche à faire dévier le système de sa tâche. OWASP recommande notamment de vérifier les appels aux outils, de valider leurs paramètres et de limiter les permissions indépendamment du modèle. [12]

Pour l’entreprise, la conséquence de conception est précise : un contenu récupéré doit pouvoir apporter une information sans modifier les autorisations de l’application. Les essais de sécurité doivent donc chercher à provoquer des actions interdites, et vérifier leur blocage effectif. Un filtre de contenu peut compléter ces protections ; son bon fonctionnement sur quelques exemples ne démontre pas la sécurité de l’ensemble du parcours.

Quels outils permettent d’appliquer et de documenter les décisions ?

Quand une plateforme GRC devient-elle utile ?

Une plateforme GRC, pour gouvernance, risques et conformité, sert à organiser les exigences, les risques, les contrôles et les éléments qui démontrent leur réalisation. Pour les usages IA, elle peut relier l’inventaire des systèmes aux décisions d’approbation, aux évaluations fournisseurs et aux actions correctives. Son intérêt est de retrouver un état cohérent et son historique lorsque plusieurs équipes interviennent.

Nous recommandons de définir d’abord ce que l’organisation doit pouvoir retrouver : qui a approuvé cet usage, sur quelle évaluation, quels contrôles restent à réaliser et qui doit les clôturer ? Un registre partagé peut convenir à un périmètre limité. Une plateforme spécialisée se justifie lorsque les volumes, les droits d’accès, les obligations de preuve ou la coordination rendent cette gestion insuffisante.

La plateforme ne réalise pas, à elle seule, le travail d’évaluation. Les documents doivent être tenus à jour, les contrôles exécutés et les écarts instruits. Acheter un outil avant de clarifier les responsabilités peut simplement déplacer la fragmentation dans une nouvelle interface.

Que peut contrôler une AI gateway ?

Une AI gateway, ou passerelle IA, se place entre les applications et les services de modèles auxquels elles accèdent. Selon le produit et sa configuration, elle peut centraliser l’authentification, appliquer des quotas, orienter les requêtes et produire des mesures d’utilisation. La documentation d’Azure API Management présente notamment des fonctions de limitation des tokens, de contrôle des accès et de répartition des appels. [8]

Pour une organisation qui exploite plusieurs applications, cette centralisation peut faciliter l’application de règles communes et l’attribution des consommations aux usages. Elle doit être conçue avec les applications : une règle n’est effective que sur les flux qui la traversent. Les comptes personnels, les fonctionnalités embarquées dans des logiciels tiers ou d’autres chemins d’accès peuvent nécessiter des contrôles différents.

Une passerelle ne garantit pas la confidentialité de toutes les données ni l’exactitude des réponses. Il faut examiner ce qu’elle enregistre, les personnes qui peuvent consulter ces traces et leur durée de conservation. Il faut aussi prévoir sa disponibilité et son comportement en cas de panne. Cette brique peut compléter une architecture de contrôle ; sa nécessité dépend du périmètre et des besoins d’exploitation.

Pour que les quotas éclairent les décisions, chaque consommation doit pouvoir être rattachée à un usage ou à une application. Il faut prévoir ce qui se passe lorsqu’une limite est atteinte : mise en attente, réduction du périmètre ou reprise manuelle. Une restriction budgétaire qui bloque sans procédure le traitement des demandes clients peut déplacer le coût vers les équipes. Le contrôle technique doit donc être accompagné d’une règle d’exploitation compréhensible.

Le raccordement de cette passerelle relève aussi de la conception des échanges entre logiciels. Notre article sur l’intégration des API et la sécurisation des échanges développe les questions d’authentification, de surveillance et de documentation à prévoir. Ces principes doivent être traduits en contrôles adaptés à chaque flux IA.

Comment vérifier qu’un pilote mérite de passer en production ?

Que faut-il mesurer avant et pendant le test ?

Avant le déploiement, il faut établir une situation de référence : durée de traitement, volume, erreurs et reprises, selon le processus concerné. Pendant le test, les mêmes indicateurs doivent être suivis sur des dossiers comparables, en tenant compte de leur complexité.

Un test limité aux demandes les plus simples risque de surestimer les résultats. Il faut inclure des informations manquantes, des documents contradictoires et des situations où le système devrait demander de l’aide. Lorsque c’est possible, une comparaison simultanée avec un groupe sans assistance permet de mieux distinguer l’effet de l’outil des variations d’activité.

Le cadre volontaire AI RMF du NIST offre un repère pour organiser le travail autour de quatre fonctions : gouverner, contextualiser les risques, mesurer et gérer. Son Playbook propose des actions à adapter au contexte ; il ne présente pas une liste de mesures toutes obligatoires. [5] Dans notre approche, ces repères servent à expliciter les décisions et les preuves attendues pour chaque usage.

Le jeu d’évaluation doit rester distinct des exemples utilisés pour régler le système. Il faut conserver les versions testées et les critères de jugement, puis examiner les résultats par type de dossier. Nous recommandons de suivre aussi les refus inutiles et les situations où le système aurait dû s’abstenir : répondre à tout prix et refuser presque tout peuvent tous deux rendre le service inefficace. Une mesure de qualité doit donc être accompagnée du périmètre couvert et des limites du test.

Comment relier la qualité des réponses aux indicateurs commerciaux ?

Nous recommandons de suivre quelques indicateurs qui se répondent : le taux de dossiers acceptés sans correction majeure, le temps total jusqu’à validation, la fréquence des reprises et le coût par dossier correctement traité. Ces mesures expliquent le fonctionnement de l’outil. Les rapprocher du délai de réponse client et, lorsque le périmètre le permet, du taux de conversion aide à examiner son intérêt commercial.

Le coût doit intégrer les appels aux modèles, les connexions aux logiciels, l’hébergement, la maintenance et le temps humain consacré aux contrôles. Le coût initial de conception et d’intégration doit également être pris en compte dans l’analyse économique. Un abonnement moins cher ne garantit pas une opération moins coûteuse.

Exemple : préparer une réponse à une demande client

Un assistant retrouve les conditions contractuelles et propose une réponse, qu’un conseiller vérifie avant envoi. Le test doit mesurer la durée de recherche, de rédaction et de validation, mais aussi les corrections nécessaires et les dossiers renvoyés à un spécialiste.

Si la rédaction accélère tandis que la vérification devient plus longue, le gain total peut être faible. Si le délai baisse avec une qualité maintenue, il reste à examiner le coût et l’usage de la capacité libérée. Pour une demande de devis, le suivi peut ensuite porter sur les commandes obtenues, en tenant compte du cycle de vente. Cet exemple décrit une méthode d’évaluation, sans préjuger du résultat d’un projet client.

À quelles conditions faut-il poursuivre, corriger ou arrêter ?

Les seuils de décision doivent être fixés avant le test, selon les exigences du métier. Une erreur sur une référence documentaire et une erreur sur un montant contractuel n’ont pas la même gravité : un taux moyen peut masquer un défaut inacceptable.

Le passage en production suppose aussi un dispositif d’exploitation : responsable identifié, budget récurrent, suivi des incidents, procédure de reprise et possibilité de désactiver la fonction. Un pilote peut être prometteur tout en nécessitant encore des corrections avant son ouverture à tous les utilisateurs.

Arrêter un cas d’usage insuffisamment utile est une décision de gestion. La gouvernance sert aussi à conserver les enseignements du test et à réorienter l’investissement.

Comment faire vivre la gouvernance après le lancement ?

Que faut-il réexaminer lorsque le système évolue ?

Un changement de modèle, de source documentaire, de connecteur ou de permission peut modifier le comportement du service. Nous recommandons de conserver un jeu de tests représentatif et de le rejouer lors des évolutions importantes, puis de surveiller les résultats en exploitation.

Pour les composants développés, notre guide sur la gestion des versions avec Git et l’intégration continue explique comment tracer les changements et organiser leur validation. Ce suivi du code doit être complété par celui des modèles, des configurations et des sources documentaires : un historique Git ne décrit pas à lui seul l’état complet du service IA.

Les retours utilisateurs doivent alimenter ce suivi. Une correction répétée, un contournement fréquent ou une difficulté à comprendre les propositions peuvent révéler un problème que les métriques techniques ne montrent pas.

La formation doit porter sur les situations rencontrées : reconnaître une réponse insuffisamment étayée, vérifier une source, signaler un incident et savoir quand reprendre la main. Elle gagne à s’appuyer sur les parcours réellement utilisés.

Comment faire remonter les résultats jusqu’aux décideurs ?

Nous recommandons un reporting par usage qui relie le volume traité, la qualité, le coût complet, les incidents et l’indicateur commercial retenu. Les données proviennent souvent de plusieurs outils : consommation du service IA, historique applicatif, temps de validation et suivi des devis ou commandes. Il faut définir comment les rapprocher pour éviter de comparer des populations ou des périodes différentes.

Le tableau de bord doit alimenter une décision à une cadence adaptée au projet : poursuivre, limiter le périmètre, corriger un défaut ou réaffecter le budget. La fréquence d’examen d’un pilote récent peut être différente de celle d’un service stable. Chaque décision doit avoir un responsable et une échéance de suivi. Un indicateur qui n’entraîne aucun examen ne suffit pas à piloter l’usage.

Que faut-il prévoir en cas d’incident ou d’arrêt du service ?

Une réponse commerciale incorrecte, un accès indu à un document et une indisponibilité appellent des traitements différents. Nous recommandons de prévoir comment signaler le problème, le qualifier, suspendre l’usage si nécessaire et reprendre le travail par une autre voie. Les équipes doivent savoir qui peut couper une fonction et qui décide de sa remise en service.

Les traces utiles doivent permettre de comprendre la version utilisée, les informations consultées, l’action produite et les validations intervenues. Leur collecte doit rester proportionnée aux besoins, avec des accès et une conservation définis. L’analyse doit déboucher sur une correction vérifiée, puis sur l’examen des autres usages éventuellement concernés.

Pour articuler ce dispositif avec la sécurité de votre système d’information, notre article sur la gouvernance, la continuité et la gestion des incidents dans NIS2 présente les questions à examiner selon le périmètre de l’entreprise. Ce rapprochement ne signifie pas que tout usage IA relève de NIS2 : il aide à coordonner les responsabilités et les procédures lorsque plusieurs cadres concernent la même organisation.

Le retrait définitif d’un système fait également partie de la gouvernance. Il faut retirer les accès et les clés inutiles, traiter les données et documents conservés et informer les utilisateurs du changement de procédure. Le NIST inclut l’inventaire, la revue périodique et le retrait des systèmes dans sa fonction de gouvernance. [9]

Quand faire intervenir une expertise IA extérieure ?

Un appui extérieur peut être utile lorsque l’organisation doit relier des exigences métier, une architecture et des compétences qu’elle ne possède pas toutes en interne. Nous recommandons de préciser le résultat attendu de cet accompagnement : cartographie des flux, conception des permissions, intégration à un logiciel, protocole de test ou préparation de l’exploitation. Le recours à un partenaire doit laisser à l’entreprise une compréhension exploitable des décisions prises.

Le choix du prestataire doit donc porter sur sa capacité à expliquer les arbitrages et à remettre les éléments nécessaires à la maintenance : documentation des connexions, règles de fonctionnement, responsabilités et procédures de reprise. Dans le champ des applications et de l’intégration, c’est à cette articulation entre conception et exécution que Kwantic peut contribuer. Les analyses juridiques ou certifications nécessitent les compétences spécifiques correspondantes.

Par où commencer dans votre PME ?

Le premier travail pour définir les bénéfices de l’IA pour votre PME consiste à identifier les usages existants, y compris les outils employés sans validation formelle. Il faut ensuite choisir un processus délimité, désigner ses responsables et réunir les données nécessaires à un test mesurable.

Notre recommandation : avancer avec un périmètre assez restreint pour comprendre les erreurs, mais assez représentatif pour éclairer une décision. Une gouvernance utile laisse une trace simple des choix effectués et permet de revoir ceux qui ne tiennent plus.

Chez Kwantic, cette réflexion s’inscrit dans l’articulation entre applications métier, intégration du système d’information et expérience utilisateur. Pour approfondir la dimension fonctionnelle, notre article sur l’intégration de l’IA dans les applications métier présente des pistes d’usage. Le travail à mener ensuite est précis : définir ce que l’outil doit accomplir, ce qu’il peut consulter et comment son résultat sera évalué.

Vous souhaitez structurer un usage IA et vérifier ce qu’il apporte à vos équipes commerciales ? Échangeons sur vos outils et vos objectifs commerciaux.

Questions fréquentes sur la gouvernance IA des PME

Faut-il un comité IA pour commencer ?

La forme dépend de la taille de l’organisation et des risques. Pour un périmètre limité, des responsables identifiés et des décisions documentées peuvent constituer un premier dispositif de pilotage. Plusieurs usages transverses ou sensibles peuvent justifier une instance commune. Dans tous les cas, les équipes doivent savoir à qui soumettre une nouvelle demande et qui peut autoriser sa mise en production.

Une charte d’utilisation IA pour une PME suffit-elle ?

Une charte aide à expliquer les usages autorisés et les précautions attendues. Il faut aussi appliquer les droits d’accès, organiser les validations et suivre les incidents. Les règles deviennent effectives lorsqu’elles se retrouvent dans les outils et dans les pratiques quotidiennes.

Quand faut-il préférer une solution standard au sur-mesure ?

Une solution standard peut convenir si elle répond au besoin, respecte les exigences de l’entreprise et s’intègre aux outils existants. Un développement sur-mesure se justifie lorsque les règles métier, les parcours ou les connexions nécessaires dépassent ce que le produit permet raisonnablement. La comparaison doit inclure le coût d’intégration et de maintenance, les limites fonctionnelles et la capacité de l’équipe à exploiter la solution.

Notre article sur la conception d’une plateforme sur-mesure pour le B2B et l’industrie approfondit le cadrage des règles métier, l’intégration aux ERP et CRM et les tests avec les utilisateurs. Ces travaux permettent de préciser ce qui doit être adapté avant de décider si une fonction IA pour votre PME apporte une amélioration utile.

Faut-il acheter une plateforme dédiée dès le premier projet ?

Le besoin dépend du nombre d’usages, des contrôles et de la traçabilité attendus. Un registre tenu à jour, des validations explicites et les outils de suivi existants peuvent suffire pour démarrer sur un périmètre limité. Une solution spécialisée devient pertinente lorsque la coordination et le contrôle le justifient.

Sources et références

1. [1] Insee, Clément Lefebvre, « Les technologies de l’information et de la communication dans les entreprises en 2025 », Insee Première n° 2120, 21 juillet 2026. Données d’adoption portant sur 2025. https://www.insee.fr/fr/statistiques/9025878
2. [2] Erik Brynjolfsson, Danielle Li et Lindsey Raymond, « Generative AI at Work », The Quarterly Journal of Economics, vol. 140, n° 2, 2025, p. 889–942. Publication en ligne le 4 février 2025. Étude du déploiement d’un assistant auprès de 5 172 agents de support client. https://doi.org/10.1093/qje/qjae044
3. [3] CNIL, « Comment déployer une IA générative ? La CNIL apporte de premières précisions », 18 juillet 2024. https://www.cnil.fr/fr/comment-deployer-une-ia-generative-la-cnil-apporte-de-premieres-precisions
4. [4] ANSSI, « Recommandations de sécurité pour un système d’IA générative », 29 avril 2024. Référence consacrée à la sécurité technique des architectures ; elle ne couvre pas l’ensemble des enjeux de gouvernance. https://messervices.cyber.gouv.fr/guides/recommandations-de-securite-pour-un-systeme-dia-generative
5. [5] NIST, « Artificial Intelligence Risk Management Framework (AI RMF 1.0) », janvier 2023, et AI RMF Playbook. Cadre volontaire de gestion des risques, à adapter au contexte d’utilisation. https://www.nist.gov/itl/ai-risk-management-framework et https://airc.nist.gov/airmf-resources/playbook/
6. [6] ISO et IEC, « ISO/IEC 42001:2023, Information technology – Artificial intelligence – Management system », décembre 2023. Présentation publique de la norme : système de management et amélioration continue. https://www.iso.org/standard/42001
7. [7] Conseil de l’Union européenne, « Artificial Intelligence: Council gives final green light to simplify and streamline rules », 29 juin 2026. Révision du calendrier d’application des règles relatives aux systèmes à haut risque. https://www.consilium.europa.eu/en/press/press-releases/2026/06/29/artificial-intelligence-council-gives-final-green-light-to-simplify-and-streamline-rules/
8. [8] Microsoft Learn, « AI gateway capabilities in Azure API Management », documentation consultée le 26 octobre 2026. Exemple de fonctions techniques disponibles : quotas, contrôle des accès et gestion des appels aux modèles. https://learn.microsoft.com/en-us/azure/api-management/genai-gateway-capabilities
9. [9] NIST, « AI RMF Core », cadre AI RMF 1.0 de janvier 2023, fonction Govern. Responsabilités, inventaire, suivi, retrait des systèmes et risques liés aux tiers. https://airc.nist.gov/airmf-resources/airmf/5-sec-core/
10. [10] Commission européenne, AI Act Service Desk, articles 4, 6 et 26 du règlement IA, version consolidée au 27 juillet 2026 présentée par le service, consultée le 26 octobre 2026. Compétences en IA, qualification des systèmes à haut risque et obligations des déployeurs concernés. https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-4 ; https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-6 ; https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-26
11. [11] Odoo, « Security in Odoo », documentation Odoo 19.0, consultée le 26 octobre 2026. Droits d’accès aux modèles et règles d’accès aux enregistrements. https://www.odoo.com/documentation/19.0/developer/reference/backend/security.html
12. [12] OWASP, « LLM Prompt Injection Prevention Cheat Sheet », documentation consultée le 26 octobre 2026. Injections indirectes, validation des appels aux outils et principe de moindre privilège. https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html