Gouvernance de l'IA pour les requis : Pourquoi votre piste d'audit vaut plus que votre modèle IA

Que se passe-t-il quand les requis générés par l'IA n'ont pas de piste d'audit?

Mardi après-midi. Bureau du centre-ville de Montréal, troisième étage, lumières au néon. L'analyste colle une quarantaine de requis sortis d'une session ChatGPT directement dans Confluence, des bullets propres, un langage correct, des règles métier qui ont l'air plausibles, et tout le monde hoche la tête autour de la table parce que bon, ça a l'air professionnel. Trois mois plus tard? Panne en prod. Une de ces règles contredisait une contrainte d'intégration que personne n'avait attrapée. Post-mortem. Quelqu'un demande « d'où vient ce requis-là? » Silence. La conversation ChatGPT, supprimée depuis des semaines. Le prompt, la version du modèle, les contraintes que le système a pesées (ou pas), qui a approuvé le résultat : rien. Quarante requis. Zéro provenance.

Inventé? Non. J'ai vu ça se produire dans trois organisations différentes dans la dernière année seulement, et honnêtement, la première fois, j'ai été surpris à quel point la piste disparaissait complètement. On génère des requis avec l'IA, on les capture dans des documents, des équipes les exécutent. Personne le long du chemin n'a de visibilité sur le raisonnement du modèle, ses angles morts, son niveau de confiance réel. Quelque chose plante? Pas de piste d'audit. Un régulateur se pointe? On a de la documentation qui prouve absolument rien. Pantoute.

Regardez, les conséquences financières sont déjà réelles. Déjà là. En janvier 2025, l'autorité italienne de protection des données (le Garante) a collé 15 millions d'euros d'amende à OpenAI pour violations du RGPD. Pas parce que l'IA était « mauvaise » en soi. Non. Parce que l'entreprise traitait des données personnelles sans fondement juridique, sautait la vérification de l'âge, et ne pouvait pas démontrer de documentation transparente sur l'utilisation des données. Le message des régulateurs? Direct : si tu peux pas le documenter, tu peux pas le défendre.

Et ça empire. (Au début, je pensais que la Loi sur l'IA de l'UE concernait surtout la santé et la finance. Je me trompais.) La Loi entre pleinement en vigueur en 2026. Elle exige des contrôles documentés pour les systèmes à haut risque, tous secteurs confondus. Le NIST AI Risk Management Framework et ISO/IEC 42001 demandent tous les deux une surveillance continue, de la traçabilité, une gouvernance documentée. Côté américain, l'Operation AI Comply de la FTC enquête activement sur la prise de décision non documentée. Si on génère des requis avec l'IA sans aucune couche de gouvernance? On assemble une bombe à retardement réglementaire. Mèche courte.

À quoi ressemble un processus de requis IA gouverné?

Six couches. C'est là qu'on a atterri quand on a commencé à concevoir notre propre modèle de gouvernance, parce que je n'arrêtais pas de poser la même question à tout le monde autour de la table : c'est quoi le minimum de contrôles qui tient vraiment la route face à un audit? Pas six parce que c'est un chiffre magique. Six parce que chacune couvre un mode de défaillance distinct qu'on avait observé dans de vrais projets à Montréal, à Toronto, à Québec.

Premièrement, le suivi des sources. Basique. Chaque requis généré par l'IA est taggé : quel modèle, quel prompt, quelle version, qui a lancé la demande. Ça a l'air évident, non? Vous seriez surpris combien d'équipes sautent cette étape, même des équipes brillantes avec des pipelines CI impeccables. Sans ça, on ne peut même pas répondre à la question la plus simple d'un auditeur : « Qui a décidé d'utiliser l'IA pour cette règle d'affaires-là? »

Deuxièmement, l'évaluation de la confiance. L'IA rapporte sa propre incertitude. Ce chiffre voyage avec le requis partout. Score de 95%? On passe plus vite. Un 65%? Drapeau automatique, examen supplémentaire requis. Au début, je pensais que les scores de confiance c'était juste du bruit, un chiffre que le modèle inventait pour avoir l'air intelligent. Je me trompais. C'est vraiment utile pour prioriser l'effort de révision, surtout quand on se noie dans 200+ requis générés un mardi matin.

Troisièmement, la validation des normes. Avant même qu'un humain regarde le requis? Vérification automatisée. Compatible avec l'architecture existante? Viole une politique de conformité? En conflit avec quelque chose déjà approuvé? Cette barrière attrape environ le tiers des problèmes dans nos tests. Le tiers. Ce qui libère les réviseurs pour les cas plus complexes où le jugement humain fait vraiment la différence.

Quatrièmement, le workflow de révision. Un expert humain examine le résultat, vérifie le raisonnement, valide le score de confiance, approuve ou rejette explicitement. Le dossier d'approbation capture le nom du réviseur, l'horodatage, et un commentaire obligatoire qui explique pourquoi. Pas « approuvé ». Pas sans contexte. Une vraie justification.

Cinquièmement, la barrière de mise en oeuvre. Rien ne sort. Rien. Pas tant que tous les contrôles ne sont pas passés. Validation incomplète, approbations manquantes, confiance faible sans escalade : rien de ça n'atteint les équipes qui vont construire à partir du requis. Un lead technique dans une compagnie de logistique à Boucherville m'a dit que cette seule barrière avait prévenu deux quasi-incidents dans leur premier mois d'utilisation.

Sixièmement, le journal d'audit immuable. Chaque action, chaque décision, chaque approbation est écrite dans une piste qu'on ne peut plus modifier après coup. Ce que le modèle a généré, quand c'a été évalué, qui l'a révisé, pourquoi c'a été approuvé, quand c'a été livré. Les régulateurs se pointent? On leur remet le journal. En minutes.

Voilà. Le pipeline au complet. Six couches qui séparent « on a utilisé l'IA pis on a espéré que ça marche » de « on a utilisé l'IA et on peut prouver que chaque décision a été gouvernée ». La différence entre un risque et un atout? Documentation.

Pourquoi la traçabilité des requis est critique à l'ère de l'IA?

Avant? Je pensais que la traçabilité c'était surtout un mal de tête pour les compagnies pharma et les contractants militaires. Des industries ultra-réglementées, OK, elles avaient besoin de pistes papier parce que le coût d'une décision non documentée pouvait être catastrophique. Mais voici ce qui m'a fait changer d'avis. Une entreprise SaaS de taille moyenne (genre 400 employés, aucune obligation réglementaire) a perdu un contrat entreprise parce que l'équipe d'approvisionnement du client a demandé comment les fonctionnalités générées par l'IA avaient été validées. La réponse? Essentiellement un haussement d'épaules. Contrat perdu. La traçabilité, c'est plus juste une affaire de conformité. C'est une affaire de crédibilité.

Pensez-y deux secondes. Quand un analyste humain rédige un requis, on peut habituellement remonter la chaîne : ticket Jira, fil Slack où trois personnes se sont obstinées sur la portée, notes de la réunion de mercredi où Sarah du produit a dit « non, l'intégration doit supporter v2 et v3 ». Le nom de l'analyste est sur le document. Six mois plus tard, quelque chose plante? On peut reconstruire le raisonnement.

Maintenant, comparez avec un requis généré par l'IA. Rien. Pas de conversation à retracer, pas de débat entre parties prenantes, pas de raisonnement documenté. Le résultat se matérialise à partir d'un prompt que personne a sauvegardé, produit par une version de modèle que personne a notée. Un régulateur (ou honnêtement, juste votre propre équipe QA) demande : « Qui a validé ça? Quels contrôles existaient? Qui a approuvé? » Personne peut répondre. Ce silence-là? C'est la violation.

La Loi sur l'IA le dit explicitement pour les systèmes à haut risque : des contrôles documentés, récupérables sur demande. Point. Le NIST AI RMF va plus loin et exige une surveillance continue, pas un audit qu'on fait une fois en Q4 et qu'on oublie jusqu'au prochain cycle budgétaire. Les organisations qui utilisent l'IA pour leurs requis ont besoin de preuves que chaque requis a été évalué, chaque décision du modèle révisée, chaque résultat validé. Pas « on a un processus ». Des preuves concrètes. Horodatées.

La traçabilité, c'est pas de la bureaucratie. (Je sais que ça en a l'air, surtout à 18h un vendredi quand on veut juste livrer et aller souper.) C'est une assurance. L'écart entre « on a généré ça avec l'IA pis on a espéré que ça marche » et « on a généré, validé contre nos normes, fait approuver par un réviseur nommé, et documenté chaque étape »? C'est l'écart entre la responsabilité juridique et la défendabilité.

Comment intégrer la gouvernance à votre processus de requis assisté par l'IA

Bonne nouvelle. Et je le pense sincèrement. On n'a pas besoin d'engager une équipe de conformité ou d'acheter une nouvelle plateforme pour faire ça correctement. Ce qu'il faut, c'est tisser la gouvernance dans le workflow lui-même, de sorte que les gens qui font le vrai travail la remarquent à peine, mais qu'un auditeur voit un dossier complet et défendable.

On commence par l'attribution de source. Chaque fois que l'IA génère un requis, on capture le contexte complet : nom du modèle, texte du prompt, qui a lancé la demande, le résultat brut. On stocke ce dossier juste à côté du requis. Pas dans un SharePoint que personne visite. J'ai vu des équipes essayer l'approche du « journal de gouvernance séparé ». Abandonné. En dedans de deux mois, chaque fois. La proximité, c'est tout.

Ensuite, l'évaluation de la confiance. Simple. Les requis bien définis scorent haut. Ceux qui sont ambigus avec cinq parties prenantes et des priorités qui se contredisent? Plus bas, évidemment. Ce chiffre suit le requis partout, visible pour chaque réviseur. Si le modèle donne ses propres métriques d'incertitude, on les utilise; sinon, on estime selon la complexité et le chevauchement entre le prompt et le domaine d'entraînement du modèle. (On a constaté que les prompts spécifiques au domaine scoraient systématiquement 15 à 20 points plus haut que les génériques, ce qui fait du sens intuitivement.)

La validation des normes. Avant que quiconque révise un requis? Checklist automatisée. Violations de sécurité, conflits avec des requis déjà approuvés, incompatibilités architecturales, langage vague ou non testable. Une équipe dans une fintech à Toronto attrapait 28% de leurs problèmes à cette étape seule. Vingt-huit pour cent. Avant même qu'un réviseur humain regarde le résultat.

L'approbation explicite, obligatoire. Aucun requis généré par l'IA n'entre en planification de production sans qu'un humain nommé signe. Et pas juste en cliquant « approuver ». Le dossier doit inclure qui, quand, et un commentaire obligatoire qui explique la justification. « Ça a l'air correct »? Ça compte pas. « Validé par rapport au SLA de traitement des paiements et confirmé avec l'équipe ops le 14 mars »? Ça, oui.

Le contrôle de mise en oeuvre. Rien ne sort tant que chaque barrière n'est pas passée. Confiance faible sans escalade, validation incomplète, approbations manquantes : rien de ça n'atteint les développeurs qui vont construire à partir de ces requis-là. Ça a l'air évident. Mais vous seriez surpris combien d'équipes sautent cette étape et laissent des résultats non révisés se faufiler dans le sprint backlog un vendredi à 16h.

Les journaux d'audit immuables. Chaque action est consignée. Quand c'a été généré, ce que le modèle a produit, quand c'a été évalué, quelles normes n'ont pas passé, qui l'a révisé, quand c'a été approuvé, quand c'a été livré. Le journal ne peut pas être modifié ou supprimé après coup. C'est la preuve de conformité. Un régulateur la demande? Minutes. Pas semaines.

Fait que voici la réalité pratique (et j'ai appris ça à la dure après avoir regardé un projet de rétrofit traîner pendant quatre mois à Québec) : si on commence avec les nouveaux requis générés par l'IA aujourd'hui, l'investissement en gouvernance est minimal. Rétrofitter des milliers de requis existants avec l'attribution de source et des scores de confiance? Cher. Sujet aux erreurs. Franchement épuisant. Mieux vaut commencer par les nouveaux projets, intégrer la gouvernance dès le jour un, et les frais généraux tombent à presque zéro parce que la gouvernance devient la façon dont le travail se fait, pas un fardeau empilé par-dessus.