Plan de gouvernance. L'artefact écrit qui accompagne chaque mise en œuvre d'ia : un document de politique décrivant ce que l'ia peut et ne peut pas décider, un log d'audit montrant chaque action et son résultat, et un plan de rollback qui ramène l'opération à son état pré-ia.
La plupart des cabinets de conseil en ia livrent du code. Nous, on livre du code plus un plan de gouvernance. Le plan de gouvernance n'est pas une option à ajouter ni un détail de dernière semaine. Il est dans le contrat dès le premier jour, et il est livré avec la mise en œuvre.
#Pourquoi la gouvernance est dans le périmètre, pas en dehors
Le motif qui revenait sur les premières missions, c'était celui-ci : une équipe passe des semaines à construire et livrer un workflow ia. Il part en production. Puis quelqu'un pose une question à laquelle l'équipe ne peut pas répondre proprement. Qui a approuvé cette décision ? Que se passe-t-il si le modèle produit une mauvaise réponse à grande échelle ? Comment revenir au process précédent si on en a besoin ?
Ces questions ne sont pas des cas limites. Ce sont les premières questions qu'un responsable risque, une équipe juridique ou un nouveau responsable opérations posera. Si les réponses ne sont pas documentées — pas dans la config du modèle, pas dans un readme, mais dans un artefact écrit lisible — le workflow ia repose sur un terrain mou.
On met la gouvernance dans le périmètre parce que livrer sans elle, c'est une livraison incomplète. Le workflow tourne, mais l'organisation n'est pas prête à en être propriétaire.
#Ce que contient vraiment le plan de gouvernance
Trois documents, rédigés et testés en parallèle de la mise en œuvre.
- document de politique — ce que l'ia est autorisée à décider, ce qu'elle doit escalader à un humain et ce qu'elle ne doit jamais faire. écrit pour l'équipe opérations, pas pour les ingénieurs.
- spec du log d'audit — le schéma et les règles de rétention pour chaque action ia. Qui a agi, sur quelle entrée, avec quelle sortie, à quelle heure. C'est le document que votre équipe conformité finira par demander.
- plan de rollback — instructions pas à pas pour ramener le workflow à sa version manuelle ou antérieure. Testé, pas théorique. Une personne nommée est propriétaire du plan.
Le document de politique a-t-il besoin d'un avocat ?
Pas pour la première version. Le document de politique est un document opérationnel, pas juridique. Il décrit ce que l'ia fait et ce que les humains possèdent. Si votre organisation a plus tard besoin d'une politique formelle d'usage de l'ia pour la conformité ou la régulation, le document de politique est la base de preuves qui rend l'écriture plus rapide. On vous le remet à votre équipe en langage clair.
#La conversation qui arrive souvent en cours de projet
Sur de nombreuses mises en œuvre, une partie prenante — souvent un directeur financier, un responsable conformité ou un directeur des opérations absent du brief initial — arrive dans le projet en cours de route. Les questions qu'elle pose sont prévisibles : que fait ce modèle quand il se trompe ? Qui est responsable ? Quelle est la pire défaillance et comment s'en remet-on ?
Quand ces questions arrivent et que le plan de gouvernance existe déjà, la réunion est courte. Quand elles arrivent et que l'équipe doit construire les réponses après coup, le projet ralentit, parfois s'arrête et est parfois annulé. Le plan de gouvernance est le document qui évite qu'une réunion en cours de projet devienne un long retard.
We are
On livre trois artefacts écrits — politique, spec de log d'audit, plan de rollback — dans le cadre du périmètre convenu. Le plan de gouvernance est testé, rédigé en langage clair, et possédé par votre équipe dès le premier jour.
We aren't
Des cabinets qui ajoutent la gouvernance comme module supplémentaire après la mise en production, ou des slides qui décrivent des « principes d'ia responsable » sans nommer une seule procédure de rollback.
#Ce que demande sa production
Le plan de gouvernance est un travail en plus d'une mission de mise en œuvre standard. Un ingénieur senior et un stratège le rédigent en parallèle de la phase finale de tests, donc il ne retarde pas la livraison. Il fait partie du périmètre convenu lors de l'appel découverte.
Les missions de gouvernance autonomes — pour les organisations qui ont déjà de l'ia en service et ont besoin des artefacts écrits — sont cadrées par écrit lors de l'appel découverte. La forme est un audit de l'ia en service plus les trois documents : le document de politique, la spec du log d'audit et le plan de rollback — que nous livrions ou non le build. Si l'ia est déjà en production et que le plan de gouvernance manque, l'audit identifie d'abord ce qui est nécessaire.
#Pourquoi on l'a rendu non-optionnel
La raison la plus simple : un workflow ia sans plan de gouvernance, c'est un produit incomplet. Il peut tourner aujourd'hui. Il causera des problèmes dès qu'un membre de l'équipe change, qu'un régulateur pose une question ou que les sorties du modèle bougent de façon inattendue.
La deuxième raison : les options à ajouter sont celles qui sautent dans les négociations de périmètre. La gouvernance n'est pas une feature. C'est la preuve que la mise en œuvre a été faite correctement.
On est nouveaux. Les conditions sur cette page sont celles qu'on honorera avec le premier client qui signe. Si vous cadrez une mise en œuvre d'ia et voulez voir à quoi ressemble un plan de gouvernance avant de vous engager, réservez un appel découverte de 30 min. On parcourra un exemple anonymisé sur l'appel.
Vendez-vous des plans de gouvernance pour une ia que vous n'avez pas construite ?
Oui. Les missions de gouvernance autonomes sont cadrées par écrit lors de l'appel découverte, avant tout travail. Le livrable est constitué des trois mêmes documents (document de politique, spec du log d'audit, plan de rollback), rédigés après un audit de l'ia en service. Pour les organisations qui ont déployé vite et ont besoin de la base écrite avant l'arrivée de la conversation sur la conformité.
