Gestion des politiques internes : le guide d’achat à l’ère de l’IA

L’essentiel

• La gestion des politiques internes a longtemps été jugée sur trois critères : le stockage, le circuit de validation et l’attestation de lecture. Depuis 2025, elle est aussi jugée sur sa capacité à produire une preuve opposable.
• Le règlement européen sur l’IA transforme la politique en livrable réglementaire : l’article 4 impose des mesures de littératie en IA aux fournisseurs comme aux déployeurs, et l’article 53, paragraphe 1, point c) impose aux fournisseurs de modèles d’IA à usage général de mettre en place une politique en matière de droit d’auteur.
• La mesure A.2 de l’annexe A d’ISO/IEC 42001 exige une politique d’IA documentée, alignée sur les autres politiques de l’organisation et revue à intervalles planifiés.
• Une attestation prouve qu’un document a été ouvert. Elle ne prouve ni qu’un contrôle fonctionne, ni quoi que ce soit au sujet des outils d’IA qui ne figurent pas à votre inventaire.
• Le critère d’achat déterminant est la démontrabilité : politique reliée au contrôle, contrôle relié à un responsable et à une date, chaîne complète exportable pour n’importe quelle période passée.

Ce que fait réellement un logiciel de gestion des politiques internes

La gestion des politiques internes consiste à centraliser le cycle de vie des règles de l’entreprise : rédaction, relecture, validation, publication, diffusion, accusé de réception, surveillance, revue périodique et retrait. La catégorie existe parce que ni les disques partagés ni les fils de courriels ne savent répondre à la seule question qui compte lors d’un audit : quelle version de quelle règle s’appliquait à quelles personnes, à une date donnée. La plupart des acheteurs arrivent en cherchant une meilleure bibliothèque documentaire. C’est la partie la moins intéressante du sujet. Quatre capacités distinguent un véritable outil de gestion des politiques internes d’un dossier bien rangé :

• La séparation imposée entre rédaction et validation. Celui qui rédige ne peut pas être celui qui approuve, et le système conserve les deux identités ainsi que l’horodatage de l’approbation.
• La reconstitution à une date antérieure. Vous pouvez montrer ce que disait la version publiée le 14 mars, et non uniquement ce qu’elle dit aujourd’hui.
• L’accusé de réception ciblé. Seul le sous-ensemble pertinent de collaborateurs est sollicité, selon le rôle, l’entité juridique ou le système concerné, et les exceptions restent visibles.
• L’export d’audit. La preuve sort de l’outil dans un format que l’évaluateur peut lire sans disposer d’une licence.

Tout le reste, y compris les assistants de rédaction par IA désormais intégrés à la plupart des produits, relève du confort d’usage. Si ces quatre capacités sont faibles, aucune qualité d’interface de rédaction ne sauvera l’audit. C’est exactement la logique qui sépare une base documentaire d’un véritable dispositif de conformité et de gouvernance.

Politique, norme, procédure : la distinction qui détermine votre outillage

Une politique énonce l’intention et désigne le responsable. Une norme fixe le seuil mesurable. Une procédure décrit les étapes. Les organisations qui fondent les trois en un seul document se condamnent à réécrire l’ensemble dès qu’un paramètre technique évolue, ce qui explique le glissement systématique de leurs cycles de revue. Les outils se distinguent nettement sur ce point : certains ne modélisent qu’un type de document unique et plat, d’autres modélisent une hiérarchie dans laquelle une norme peut évoluer sans rouvrir la politique qui l’autorise. Si vos contrôles d’IA doivent être révisés plus souvent que votre intention de gouvernance, et ce sera le cas, exigez la hiérarchie.

Pourquoi 2026 change les exigences

Disposer d’une politique relevait jusqu’à récemment de la bonne pratique. Pour quiconque conçoit ou déploie de l’IA, il s’agit désormais d’une obligation juridique adossée à des articles précis. L’article 4 du règlement européen sur l’IA, consacré à la maîtrise de l’IA, s’applique depuis le 2 février 2025. Il dispose que « les fournisseurs et les déployeurs de systèmes d’IA prennent des mesures pour garantir, dans la mesure du possible, un niveau suffisant de maîtrise de l’IA de leur personnel et des autres personnes s’occupant du fonctionnement et de l’utilisation des systèmes d’IA pour leur compte ». Ces mesures doivent être consignées, ciblées sur les bons profils et tenues à jour. Or le registre de qui a suivi quelle formation est précisément ce qu’un outil de gestion des politiques internes est censé conserver. L’article 53, paragraphe 1, point c) va plus loin pour les fournisseurs de modèles d’IA à usage général, tenus de « mettre en place une politique visant à se conformer au droit de l’Union en matière de droit d’auteur et de droits voisins ». La formulation mérite attention. L’obligation ne consiste pas à bien se comporter, elle consiste à disposer d’une politique, et l’autorité compétente peut en exiger la production. Notre guide sur les obligations applicables à l’IA à usage général détaille le reste de ce régime. Les normes vont dans le même sens. La mesure A.2 de l’annexe A d’ISO/IEC 42001 impose une politique d’IA documentée, alignée sur les autres politiques de l’organisation et revue à intervalles planifiés au regard de sa pertinence et de son efficacité. L’article 7.5 en fait une information documentée obligatoire, si bien que l’auditeur la réclamera nommément lors de la certification. Le NIST AI RMF est cohérent avec cette approche : la sous-catégorie GOVERN 1.2 attend que les caractéristiques d’une IA digne de confiance soient intégrées aux politiques, processus, procédures et pratiques de l’organisation, tandis que GOVERN 1.1 attend que les exigences légales et réglementaires soient comprises, gérées et documentées. Le contexte national ajoute une couche. La CNIL publie depuis plusieurs années des recommandations pratiques sur l’articulation entre systèmes d’IA et RGPD, et l’ANSSI documente les exigences de sécurité applicables aux systèmes d’information qui hébergent ces traitements. Une politique d’IA rédigée en France doit pouvoir se raccorder à ces deux corpus sans réécriture, ce qui suppose un outil capable de porter plusieurs référentiels sur une même clause. La conséquence pratique, pour quiconque établit une liste restreinte de solutions de gestion des politiques internes, tient dans un déplacement de la question posée. L’ancienne question était de savoir si l’outil savait diffuser un document à tout le monde et enregistrer son ouverture. La nouvelle est de savoir s’il sait fournir à un évaluateur une réponse défendable à une demande étroite et désagréable : montrez-moi la politique qui satisfait cette obligation, la version en vigueur sur la période revendiquée, les personnes auxquelles elle s’appliquait, et la preuve que le contrôle sous-jacent a effectivement fonctionné. Les produits conçus comme des moteurs de diffusion répondent très bien à la première question et très mal à la seconde.

Le piège de l’attestation : une signature n’est pas une conformité

Tous les produits de la catégorie comptabilisent les attestations, et la plupart des guides d’achat en font l’indicateur principal. C’est un mauvais indicateur. Une attestation enregistre qu’une personne identifiée a ouvert un document et cliqué pour confirmer. Elle n’enregistre ni sa compréhension, ni un changement de comportement, ni le fonctionnement effectif du contrôle décrit par la politique. Un service peut afficher 100 % d’accusés de réception sur une charte d’usage tout en exploitant en production un modèle jamais revu, et le tableau de bord restera au vert du début à la fin. L’écart se creuse avec l’IA. Une charte d’usage ne couvre que les outils que vous connaissez. Le shadow AI, c’est-à-dire les modèles et assistants adoptés par les équipes sans passer par le moindre processus d’entrée, échappe par construction à toute attestation : un outil jamais entré à l’inventaire n’a jamais figuré dans le périmètre d’une campagne d’accusé de réception. Un taux de couverture mesuré sur un registre auquel il manque un tiers du parc mesure le registre, pas la conformité. Ce que l’évaluateur demande, à la place, est une chaîne. Quelle obligation impose ce contrôle, quelle politique l’énonce, qui en est responsable, et quelle preuve établit son fonctionnement sur la période revue. Un outil qui s’arrête à « publié, 94 % d’accusés de réception » vous laisse reconstituer cette chaîne à la main, dans un tableur, la semaine précédant l’audit. C’est le test pratique de l’auditabilité, et c’est là que s’arrête l’outillage documentaire et que commence l’outillage de gouvernance. Rien de tout cela ne rend l’attestation inutile. Elle reste le moyen le moins coûteux d’établir qu’une règle a été communiquée, et la communication constitue un élément juridique réel de plusieurs obligations, dont le devoir de littératie évoqué plus haut. L’erreur consiste à traiter le pourcentage d’accusés de réception comme un résultat plutôt que comme une donnée d’entrée parmi d’autres. Lisez-le comme un indicateur de diffusion, conservez-le, puis posez séparément la question difficile : pour chaque politique, quel artefact indépendant convaincrait quelqu’un qui ne nous fait pas confiance que la règle a été suivie ?

Neuf critères d’évaluation qui comptent désormais

Les grilles de fonctionnalités de cette catégorie comportent une cinquantaine de lignes, dont la quasi-totalité est satisfaite par tous les produits. Ces neuf critères les départagent.

1. Le chaînage politique, contrôle, preuve. Une clause peut-elle pointer vers un contrôle, et ce contrôle vers l’artefact prouvant son exécution ? Si la réponse est un lien vers un dossier partagé, il n’y a pas de chaînage.
2. La cartographie multiréférentiels. Une même politique satisfait généralement plusieurs obligations à la fois. Une clause unique doit pouvoir porter simultanément ses correspondances vers le règlement européen sur l’IA, ISO/IEC 42001 et le NIST AI RMF, faute de quoi ajouter un référentiel revient à réécrire la bibliothèque. Notre cadre de gouvernance de l’IA détaille la logique de correspondance.
3. Le déclenchement des revues par événement. Les cycles annuels ont été conçus pour une réglementation stable. Vérifiez qu’une revue peut être déclenchée par un nouveau texte, un changement de version de modèle ou un incident, et pas seulement par une échéance calendaire.
4. Les dates d’effet et la succession des versions. Un numéro de version ne suffit pas. Il faut une date d’entrée en vigueur, une chaîne de remplacement et la capacité de répondre à la question de ce qui était en vigueur à un instant passé quelconque.
5. L’attestation ciblée. Un accusé de réception adressé selon le rôle, l’entité juridique, la juridiction ou le système d’IA concerné, avec une file d’exceptions visible. Les campagnes indifférenciées produisent des chiffres flatteurs et peu de signal.
6. Le rattachement à l’inventaire. La bibliothèque de politiques doit s’appuyer sur le même référentiel que votre inventaire de systèmes d’IA. Maintenus séparément, les deux divergeront, et cette divergence deviendra le constat d’audit.
7. Des données structurées et exportables. Des politiques conservées uniquement en PDF ne peuvent être ni interrogées, ni comparées, ni transmises à des contrôles en aval. Demandez une interface programmable et un export structuré avant de demander des modèles de document.
8. Une piste d’audit inaltérable. Chaque changement d’état journalisé, le journal lui-même étant protégé contre toute modification par les administrateurs.
9. La délégation de rédaction avec séparation maintenue. Les experts métier rédigent sur leur périmètre pendant que l’autorité d’approbation reste au responsable désigné.

Ce qui distingue les catégories d’outils

Citer des produits vieillit vite et n’apprend pas grand-chose, la parité fonctionnelle étant atteinte sur ce marché une ou deux versions après toute nouveauté réelle. Les catégories sont plus stables, car elles reflètent l’origine de chaque produit. Quatre familles se partagent aujourd’hui la gestion des politiques internes, et chacune porte les hypothèses du problème qu’elle a été conçue pour résoudre. Les suites de maîtrise documentaire sont issues du management de la qualité et de l’accréditation du secteur public. Le cycle de vie, le versionnement et l’attestation y sont excellents, souvent les meilleurs du marché. La cartographie réglementaire y reste superficielle, et les obligations propres à l’IA sont absentes ou traitées comme un type de document banal. Les plateformes GRC transverses relient les politiques aux risques, aux contrôles et aux réglementations comme fonction de premier rang, ce qui correspond exactement au premier critère. Le prix à payer est la configuration : ces déploiements se comptent en trimestres, et le contenu relatif à l’IA se présente le plus souvent comme un module ajouté sur un modèle de données antérieur à l’IA. Les outils d’intranet et de suite bureautique l’emportent sur l’adoption, puisque les collaborateurs y sont déjà, et sur le prix, la licence étant souvent déjà payée. Ils sont les plus faibles sur la rigueur probatoire : la séparation des rôles, l’inaltérabilité des journaux et la reconstitution à une date antérieure y relèvent de la convention plutôt que d’un comportement imposé par le système. Les plateformes de gouvernance nativement conçues pour l’IA partent de l’obligation plutôt que du document, si bien que les politiques y arrivent déjà reliées aux contrôles et à un inventaire de systèmes d’IA. La catégorie étant plus jeune, la couverture des sujets extérieurs à la gouvernance de l’IA y est inégale. La plupart des organisations possèdent déjà un outil relevant des trois premières familles. La question réaliste est donc rarement celle d’un remplacement complet, mais celle de la couche qui détiendra la preuve. Nous traitons cet arbitrage en détail dans notre analyse des outils de gouvernance de l’IA.

La question du « on le construit sur SharePoint »

Construire sur une plateforme documentaire existante se défend lorsque le nombre de politiques est faible, qu’aucun régulateur sectoriel n’est dans la boucle et que personne ne vous a encore demandé de reconstituer un état passé. Cela cesse de se défendre le jour où vous avez besoin d’une séparation imposée des rôles et d’un journal inaltérable, car l’une comme l’autre devront être développées, puis maintenues au fil des évolutions de la plateforme sous-jacente. Budgétez la maintenance, pas seulement la construction.

Vers des politiques lisibles par machine

La génération actuelle d’outils traite la politique comme un document auquel on attache des métadonnées. La trajectoire va vers la politique comme donnée structurée, exploitable par les systèmes eux-mêmes. La formulation publiée la plus nette de cette idée est la proposition des Policy Cards (Mavracic, octobre 2025), qui soutient que les Model Cards, Data Cards et System Cards décrivent un système mais lui manquent une couche normative opérationnelle. Les Policy Cards encodent des règles d’autorisation et d’interdiction, des obligations et des exigences de preuve qu’un agent applique à l’exécution, avec des correspondances vers le NIST AI RMF, ISO/IEC 42001 et le règlement européen sur l’IA. Que ce format précis s’impose ou non, le besoin qu’il traduit est déjà réel pour quiconque déploie des agents d’IA autonomes. Un agent ne peut pas lire un PDF et en déduire qu’il lui est interdit de transmettre des données clients à un modèle externe. La contrainte doit exister sous une forme que le moteur d’exécution sait évaluer. Un acheteur qui engage une décision pluriannuelle a donc intérêt à pondérer la représentation structurée des politiques et l’ouverture du format d’export plus lourdement que l’ergonomie de l’éditeur.

Un plan d’évaluation en 30 jours

Semaine 1 : inventorier l’existant. Recensez chaque politique, norme et procédure avec son responsable, sa date de dernière validation et sa prochaine échéance de revue. La plupart des organisations découvrent deux choses : plusieurs documents n’ont aucun responsable, et le total dépasse toutes les estimations. N’achetez rien à ce stade. Semaine 2 : relier les documents aux obligations. Pour chaque élément, notez l’obligation qui l’impose. Certains ne se rattacheront à rien, ce qui signale en général un document hérité. Plus utile encore, dressez la liste inverse : les obligations qui ne se rattachent à aucun document. Du côté de l’IA, ce vide recouvre le plus souvent les mesures de littératie de l’article 4, une position d’usage acceptable sur les outils génératifs et une règle de gestion des changements de modèle. Semaine 3 : piloter deux politiques de bout en bout. Choisissez une politique simple et une politique touchant à l’IA. Faites-les circuler dans chaque outil présélectionné, de la rédaction à l’accusé de réception ciblé, puis exportez la preuve. C’est l’export qui constitue le test, pas le circuit de validation. Semaine 4 : conduire un audit à blanc. Choisissez une date située trois mois en arrière et demandez à chaque outil ce qui était alors en vigueur, qui en avait accusé réception, et quelle preuve atteste du fonctionnement du contrôle associé. Notez chaque outil sur le volume de reconstitution manuelle exigé. Cet exercice reproduit le déroulement d’un audit d’IA et constitue la seule partie de l’évaluation qui prédise le comportement de l’outil sous contrainte.

Questions fréquentes

Qu’est-ce qu’un logiciel de gestion des politiques internes ? Un logiciel de gestion des politiques internes pilote le cycle de vie complet des règles de l’organisation : rédaction, relecture, validation, publication, diffusion, accusé de réception, revue périodique et retrait. Il remplace les disques partagés et les fils de courriels par des circuits imposés, un versionnement assorti de dates d’effet, un registre de qui a accusé réception de quelle version, et une piste d’audit couvrant chaque modification. Les produits les plus aboutis relient en outre chaque politique aux contrôles et aux obligations qu’elle sert. La gestion des politiques internes se confond-elle avec la gestion électronique de documents ? Non. Une GED stocke des fichiers et suit des versions. La gestion des politiques internes y ajoute la couche de gouvernance : séparation imposée entre rédaction et approbation, campagnes d’accusé de réception ciblées, planification des revues et restitution conçue pour des évaluateurs plutôt que pour des documentalistes. Vous pouvez construire cette gouvernance au-dessus d’une GED, mais vous en assumez alors le développement et la maintenance. Le règlement européen sur l’IA impose-t-il un logiciel de gestion des politiques internes ? Il impose des politiques, pas un produit particulier. L’article 4 oblige fournisseurs et déployeurs à prendre des mesures garantissant un niveau suffisant de maîtrise de l’IA, et l’article 53, paragraphe 1, point c) oblige les fournisseurs de modèles à usage général à mettre en place une politique de conformité au droit d’auteur. Rien ne vous contraint à acheter un outil. En pratique, dès qu’il faut prouver quelle version s’appliquait à qui et quand, le tableur cesse de tenir. Voyez notre guide opérationnel du règlement européen sur l’IA. Faut-il une politique d’IA distincte ou peut-on étendre les politiques existantes ? Les deux fonctionnent, et la mesure A.2 d’ISO/IEC 42001 attend précisément un alignement sur les autres politiques de l’organisation plutôt qu’un document isolé. Une politique d’IA distincte se prouve généralement plus facilement, car l’évaluateur qui demande la politique d’IA reçoit un artefact unique au lieu de clauses amendées réparties dans six documents. Quelle que soit la voie retenue, gardez une responsabilité nominative et un intervalle de revue explicite. Un logiciel gratuit de gestion des politiques internes suffit-il ? Pour une petite structure disposant d’une poignée de politiques et sans régulateur sectoriel, un outil gratuit ou déjà inclus dans une suite est souvent proportionné. Il cesse de l’être dès que vous avez besoin d’une séparation imposée des rôles, d’une reconstitution à une date antérieure ou d’un export de preuve, c’est-à-dire précisément des fonctions que les offres gratuites omettent. Le prix de l’outil est rarement le facteur décisif. Le coût de la reconstitution manuelle de la preuve l’est. Combien coûte un logiciel de gestion des politiques internes ? L’affichage public des tarifs reste rare dans cette catégorie. La plupart des éditeurs facturent par utilisateur et par an, assortis d’un forfait de plateforme, et le total dépend du nombre de personnes devant accuser réception des politiques bien plus que du nombre de rédacteurs. Fixez ce volume d’utilisateurs destinataires avant de solliciter des devis : c’est la variable qui pèse le plus sur le prix et celle que les acheteurs sous-estiment le plus souvent. À quelle fréquence les politiques doivent-elles être revues ? ISO/IEC 42001 exige une revue à intervalles planifiés sans fixer l’intervalle. Le rythme annuel constitue le choix courant et reste raisonnable sur des domaines stables. Pour les politiques d’IA, un intervalle calendaire seul est insuffisant, les obligations comme les systèmes évoluant entre deux cycles. Ajoutez des déclencheurs événementiels : un nouveau texte réglementaire, un changement significatif de modèle ou de fournisseur, ou un incident.

Conclusion

La catégorie se vend depuis une décennie sur la même promesse : sortir les politiques des disques partagés et prouver que les collaborateurs les ont lues. Cette promesse constitue désormais le ticket d’entrée et non plus l’élément différenciant. La réglementation a déplacé l’exigence de la diffusion vers la preuve, et l’IA l’a déplacée le plus vite, parce que les systèmes gouvernés évoluent bien plus souvent que ne l’anticipait un cycle de revue annuel. Lorsque vous évaluez une solution de gestion des politiques internes, conduisez l’audit à blanc avant la démonstration fonctionnelle. Un outil incapable de reconstituer ce qui était en vigueur le trimestre dernier, et d’en produire la preuve, ne survivra pas au contact d’un évaluateur, quelle que soit la qualité ressentie de son éditeur. Si vous construisez cette couche de preuve spécifiquement pour l’IA, commencez par notre guide de la gouvernance de l’IA.