Guide pratique
Une méthode complète, en douze chapitres, pour faire passer un flux de travaux du savoir à forte valeur du statut de candidat à une décision de mise en production. Elle vise une institution publique canadienne ou une organisation réglementée. Publiée intégralement sur cette page ; les gabarits qui l’accompagnent sont fournis sur demande.
Orientation
Voici la méthode que nous appliquons dans nos mandats. Nous la publions pour que vous puissiez la mener vous-même, la mener avec un tiers, ou la lire avant de décider de la mener avec nous. Suivez les chapitres dans l’ordre : chacun produit une pièce justificative écrite que le suivant reprend. Les chapitres 1 à 4 servent à décider s’il faut aller de l’avant. Les chapitres 5 à 8 servent à décider quoi construire et comment vous saurez que cela fonctionne. Les chapitres 9 à 12 servent à décider comment vous exploiterez le service, ce qu’il coûtera et comment vous l’achèterez.
À un responsable de programme, à un dirigeant principal de l’information (DPI), à un architecte d’entreprise ou à un responsable des risques. L’institution peut être une administration fédérale ou provinciale canadienne, une société d’État, un organisme de santé ou d’éducation, ou une institution financière fédérale. Le guide suppose un flux de travaux du savoir interne dont une personne révise déjà le résultat (note d’information, triage, recherche au centre d’assistance). Il ne vise pas une décision automatisée touchant un membre du public. Cette distinction détermine tout ce qui suit.
Chapitre 1
La résidence des données est habituellement la première question posée au sujet d’un déploiement d’IA au Canada, et elle ne règle qu’une petite partie de ce que recouvre la souveraineté.
Cela signifie que votre institution sait établir par écrit qui peut contraindre, administrer, observer, modifier, interrompre et rétablir le service. Elle agit en conséquence. La résidence des données indique où les données sont stockées et traitées. La souveraineté, elle, couvre la compétence juridique, la propriété de l’infrastructure, l’accès des administrateurs et du personnel de soutien, ainsi que la garde des clés de chiffrement. Elle couvre aussi la provenance des modèles ; la télémétrie ; le contrôle des mises à jour ; la réponse aux incidents ; et la sortie. Une région canadienne exploitée par un fournisseur sous contrôle étranger satisfait parfois à la résidence des données tout en laissant cette liste sans réponse.
Huit domaines de contrôle entourent la charge de travail encadrée, au centre. Les quatre premiers : lieu et résidence des données ; compétence juridique ; contrôle et administration de l’infrastructure ; identités et accès du soutien. Les quatre autres : chiffrement et garde des clés ; contrôle du modèle et du logiciel ; exploitation et télémétrie ; continuité et réponse aux incidents. La résidence est un contrôle parmi huit, et non un synonyme de souveraineté.
Consignez les huit domaines par écrit. Pour chacun, nommez la partie responsable, la preuve que vous avez vue et la date à laquelle vous l’avez vue. Les domaines dont la mention est « pas encore établi » constituent la liste de travail. Une revue d’architecture qui ne couvre qu’un seul de ces huit domaines n’a pas couvert la question.
L’objection évidente, c’est que tout cela pèse trop lourd pour un assistant de rédaction interne. Souvent, c’est vrai. Le principe, c’est justement la proportionnalité : la profondeur des preuves découle de la classification et de l’incidence décisionnelle que vous fixez aux chapitres 3 et 4. Mais on décide de la proportionnalité après avoir posé les questions, et non au lieu de les poser. Vous trouverez l’argumentaire détaillé dans La résidence des données au Canada n’est pas la souveraineté de l’IA. Le détail contrôle par contrôle se trouve sur la page sur l’IA souveraine.
Chapitre 2
Choisissez le premier flux de travaux en fonction de sa démontrabilité plutôt que de sa visibilité. Vous achetez une réponse : votre institution est-elle capable d’exploiter un agent encadré ? Vous voulez obtenir cette réponse à peu de frais.
Faites passer chaque candidat par cette séquence. Échouer à une étape ne disqualifie pas un flux de travaux pour toujours ; cela le disqualifie seulement comme premier choix.
Un flux où une personne révise déjà le résultat. Une mesure de base existe déjà, les documents sources sont finis et classifiables, et de 100 à 300 cas historiques réels sont prêts à tester. Concrètement : soutien aux politiques et à la recherche ; réception et triage de documents ; ou recherche de connaissances au centre d’assistance interne. Évitez, comme première charge de travail, tout ce qui décide d’un droit, d’une prestation ou d’une sanction visant un membre du public.
Notez les candidats retenus au lieu d’en débattre, à l’aide d’une matrice pondérée comme l’exemple détaillé de la page du sprint de gouvernance. Toute méthode appliquée de façon constante ramène le désaccord dans une case où la preuve peut trancher. Les trois schémas documentés sur ce site : le soutien aux politiques et à la recherche, la réception et le triage des documents, et l’agent de connaissance pour centre d’assistance.
Chapitre 3
La classification est une propriété de chaque artefact que le système touche, y compris les copies dérivées que personne ne considère comme des données.
L’échec caractéristique consiste à classifier le corpus source puis à approuver la conception. Quelqu’un découvre ensuite que les requêtes, les passages récupérés, les plongements, les jeux de données d’évaluation, les journaux, les caches et les sauvegardes sont tous des copies dérivées. Elles résident ailleurs, sous un régime de contrôle différent. Une architecture agentive produit plus de copies de vos informations qu’une application traditionnelle, et chaque copie hérite de la classification de ce dont elle est dérivée.
| Artefact | Question à trancher | Oubli fréquent |
|---|---|---|
| Corpus source | Qui possède et approuve chaque source, et à quelle classification ? | Un seul document de classification élevée dans un corpus par ailleurs peu classifié relève toute la limite. |
| Requêtes des utilisateurs | Où vont-elles, combien de temps sont-elles conservées, qui peut les lire ? | Des utilisateurs collent du contexte sensible dans une interface classifiée pour de l’information publique. |
| Passages récupérés | Franchissent-ils une limite en transit vers le modèle ? | La récupération est considérée comme interne même lorsque l’inférence ne l’est pas. |
| Plongements et index | Où résident les vecteurs, et sont-ils traités comme du contenu dérivé ? | Les vecteurs sont classés comme des métadonnées plutôt que comme une représentation de la source. |
| Jeu de données d’évaluation | S’agit-il de données de cas réels, et qui peut les détenir ? | Des jeux de données de référence constitués à partir de dossiers réels se retrouvent sur des portables non gérés. |
| Journaux et traces | Qu’est-ce qui est capté, pendant combien de temps, et qui peut l’interroger ? | La journalisation intégrale des requêtes et des réponses crée discrètement un nouveau fonds documentaire. |
| Caches et sauvegardes | Que subsiste-t-il après la suppression, et où ? | Supprimer dans l’application n’équivaut pas à supprimer dans la plateforme. |
Deux règles gardent l’exercice gérable. Concevez en fonction de la classification la plus élevée présente dans la limite, ou retirez-en les sources en cause. La seconde option est souvent la moins coûteuse. Consignez tôt la position sur les renseignements personnels : leur présence, leur nécessité et la possibilité de les réduire. Consignez la manière dont ils seront traités conformément à la Loi sur la protection des renseignements personnels et aux instruments de protection de la vie privée de votre institution. Faites intervenir votre bureau de la protection de la vie privée à cette étape, et non à la revue d’acceptation. Notre modèle de contrôle est présenté sur la page sur la sécurité et la gouvernance.
Chapitre 4
La Directive sur la prise de décisions automatisée a une portée plus étroite qu’on ne le suppose souvent, et elle vise pourtant des systèmes qui échappent souvent à l’examen. Faites le filtrage de façon délibérée et consignez le raisonnement.
Elle s’applique aux systèmes en production qui prennent des décisions administratives (ou des évaluations connexes) visant des clients, ou qui les appuient. Elle exclut les systèmes d’essai et de recherche. Un assistant de récupération qui renvoie des passages et des citations à un analyste, lequel raisonne ensuite de façon autonome jusqu’à une recommandation, tombe en général hors de cette portée. Mais la frontière relève d’un jugement que votre institution pose et consigne, et l’EIA est l’instrument qui sert à le documenter. Faites le filtrage tôt ; la réponse façonne l’architecture.
Les questions de filtrage sont courtes. Le résultat sert-il à une décision administrative visant un client ? Produit-il une note, un classement, une recommandation ou un signal d’admissibilité ? Une personne chargée de la révision l’adopterait-elle en pratique sans raisonnement autonome ? S’agit-il de production ou de recherche ? Le système touche-t-il des caractéristiques protégées ou des variables qui en tiennent lieu ? Si les réponses pointent vers la Directive, remplissez une EIA et laissez le niveau d’incidence déterminer l’obligation d’examen par les pairs. Les niveaux II à IV exigent un examen par les pairs. Les spécialistes qualifiés peuvent provenir de l’appareil gouvernemental, du milieu universitaire ou de la société civile. Ils peuvent aussi venir d’un spécialiste sous contrat ou d’un organisme désigné par le Secrétariat du Conseil du Trésor du Canada (SCT).
Avertissement
Un assistant à faible incidence peut devenir un système à forte incidence par dérive. Quelqu’un ajoute un champ de recommandation, un indice d’admissibilité ou un envoi automatique, et personne ne refait le filtrage. Intégrez ce nouveau filtrage au contrôle des changements dès le premier jour : le déclencheur devient le changement, et non la vérification.
Le traitement complet se trouve dans quand un assistant d’IA déclenche-t-il une évaluation de l’incidence algorithmique. Les institutions financières fédérales mènent l’exercice parallèle au regard de la ligne directrice E-23 : Gestion du risque de modélisation du Bureau du surintendant des institutions financières (BSIF). Cette ligne directrice entre en vigueur le 1er mai 2027 et vise les modèles d’IA et d’apprentissage automatique, y compris ceux de tiers. Voir la ligne directrice E-23 du BSIF et les agents d’IA.
Chapitre 5
Six étapes, chacune dotée d’un responsable désigné, d’un test d’acceptation et d’un mode de défaillance documenté. Un contrôle sans test d’acceptation ne peut pas être démontré lors d’une revue d’incident.
Six étapes de contrôle reliées entre elles. Une : sources approuvées et classification des données. Deux : identité et accès aux outils selon le droit d’accès minimal. Trois : contrôles des modèles et des requêtes. Quatre : évaluations et seuils d’acceptation. Cinq : approbation humaine et escalade. Six : surveillance, vérification, incidents et contrôle des changements. L’étape six renvoie ses données probantes à toutes les étapes précédentes.
Un corpus nommé et versionné, avec un responsable par source.
Les droits d’accès sont appliqués à la couche de récupération, et non dans la requête.
Versions figées, requêtes versionnées, provenance et licence consignées, retour arrière testé.
Un jeu de données de référence assorti de seuils chiffrés convenus avant la construction.
Un point de contrôle explicite, une escalade en un clic, un résultat consigné.
Des demandes traçables, des incidents classifiés, un contrôle des changements couvrant le modèle, les requêtes, les connecteurs et le corpus.
L’étape 06 est celle qu’un budget omet le plus facilement, parce que c’est la seule qui exige un effort continu après la mise en production. Prévoyez-en le budget au chapitre 10.
Chapitre 7
Trois formes couvrent la plupart des charges de travail d’agents de connaissance au Canada. Chacune procure certains contrôles et les paie ailleurs. Le travail utile consiste à nommer le compromis par écrit.
| Dimension | Interface de programmation d’applications (API) gérée, région canadienne | Déploiement privé ou dédié | Modèle à poids ouverts sur une infrastructure sous contrôle canadien |
|---|---|---|---|
| Contrôle | Le plus faible. La compétence juridique, l’accès des administrateurs du fournisseur, la télémétrie et les changements de version échappent en grande partie à votre autorité. | Intermédiaire. Le cloisonnement, le chemin réseau et la garde des clés s’améliorent ; l’exploitant et sa chaîne d’approvisionnement demeurent des tiers. | Le plus fort. Le modèle, la télémétrie, la gestion des versions et le retour arrière vous appartiennent. Aucune inférence ne sort de la limite. |
| Coût | Le plus bas au départ. Paiement au jeton, sans minimum. Le coût croît directement avec l’utilisation. | Composante fixe plus élevée, souvent une capacité réservée ou des frais de plateforme, avec un coût marginal plus faible à volume élevé. | Dominé par la capacité en processeurs graphiques, payée que le système soit utilisé ou non. Le moins cher uniquement à volume soutenu. |
| Effort | Quelques jours pour obtenir un environnement fonctionnel. La charge d’exploitation se situe surtout du côté de l’application. | Quelques semaines. La mise en réseau, l’intégration des identités et l’examen des garanties du fournisseur dominent. | Des mois pour bâtir la capacité, ou le recours à un partenaire. Vous assumez la planification de la capacité, l’application des correctifs, l’évaluation et un tour de garde en exploitation. |
| Qualité du modèle | La capacité la plus avancée du moment, qui change sous vos pieds à moins de figer les versions. | Habituellement la même famille que l’API gérée, avec plus de maîtrise sur le moment des changements de version. | Solide et en progression pour les tâches de connaissance ancrées dans la récupération ; un écart subsiste pour le raisonnement le plus difficile et pour l’usage d’outils sur de longues séquences. |
| Sortie | L’application est portable ; les requêtes, les batteries d’évaluation et les plongements demandent habituellement une reprise. Vérifiez l’exportation des journaux et des index. | Les clauses contractuelles de sortie comptent plus que les aspects techniques. Confirmez ce qui part avec vous, et dans quel format. | La meilleure position : les poids, les index et l’infrastructure se trouvent déjà à l’intérieur de votre limite. La sortie est une migration, pas une négociation. |
Choisissez le modèle le moins coûteux qui satisfait à la classification et à l’incidence décisionnelle établies aux chapitres 3 et 4, et pas moins coûteux que cela. Pour du travail de connaissance interne non classifié dont la valeur reste à démontrer, une API gérée dans une région canadienne constitue habituellement le premier choix rationnel. Supposons que la télémétrie du modèle soit strictement interdite ou que le corpus porte une classification plus élevée. Un modèle à poids ouverts sur une infrastructure sous contrôle canadien est alors la position la plus solide. Tranchez au moyen d’un compromis écrit, pas d’une préférence.
Une quatrième forme, qui répartit le trafic entre deux modèles selon la classification, est légitime. Traitez la décision d’acheminement comme un contrôle évalué, doté de sa propre batterie de tests et d’un comportement par défaut de fermeture en cas de défaillance. Une demande mal acheminée est une divulgation, et non un problème de performance.
Chapitre 8
L’acceptation, c’est un chiffre comparé à un seuil convenu avant que quiconque ait construit quoi que ce soit. Sans cela, l’acceptation repose sur une démonstration plutôt que sur une mesure.
Constituez le jeu de données de référence à partir de cas historiques réels : de 100 à 300 éléments. Stratifiez-les selon les types de questions, les domaines sources, les langues et les cas limites que contient le flux de travaux. Ce sont les personnes qui font le travail qui les annotent. Un arbitre désigné tranche les désaccords, et le raisonnement est consigné. Actualisez le jeu de données selon un calendrier établi et chaque fois que le corpus ou le flux de travaux change.
| Dimension | Mesure | Seuil illustratif | Type de point de contrôle |
|---|---|---|---|
| Ancrage dans les sources | Proportion de réponses entièrement appuyées par les sources citées | Exemple : 95 % ou plus | Noté |
| Exactitude des citations | Proportion de citations qui aboutissent et qui appuient la phrase à laquelle elles sont rattachées | Exemple : 98 % ou plus | Noté |
| Exhaustivité de la tâche | Note attribuée selon une grille, par rapport à la réponse de référence | Exemple : médiane de 4 sur 5 | Noté |
| Suite de sûreté critique | Comportements interdits nommés, dont la divulgation au-delà d’une limite de droits d’accès | 100 % | Réussite ou échec |
| Limite des autorisations | Demandes faites par un utilisateur d’essai sans droit d’accès pour du contenu qu’il n’a pas le droit de voir | 100 % | Réussite ou échec |
| Abstention | Refus correct lorsque les sources approuvées ne répondent pas à la question | Exemple : 90 % ou plus | Noté |
| Temps de latence | Médiane et 95e centile jusqu’à une réponse utilisable | Exemple : médiane de 5 s, 12 s au 95e centile | Noté |
| Coût unitaire | Coût total d’inférence et de récupération par tâche terminée | Fixé par rapport au budget de référence | Noté |
Deux disciplines rendent la grille crédible. Les suites de sûreté et d’autorisations se soldent par une réussite ou un échec, jamais par une moyenne. En effet, un taux de réussite de 99 % en matière de divulgation signifie une divulgation sur cent. Et l’institution signe chaque seuil avant le début de la construction, de sorte que personne ne peut renégocier l’acceptation à la sixième semaine. Vous trouverez la méthode complète, y compris les essais en équipe rouge, l’évaluation bilingue et le point de contrôle de mise en production, dans comment évaluer un agent de connaissance.
Chapitre 9
Six semaines, jalonnées de points de contrôle hebdomadaires, qui se terminent par une décision de mise en production accompagnée de preuves. Le délai fixé empêche une démonstration sans fin qui n’est ni menée à terme ni arrêtée.
Une séquence de six semaines jalonnée de points de contrôle. Semaine un : base de référence du flux de travaux et critères d’acceptation. Semaine deux : accès sécurisé et identité, puis jeu de données d’évaluation. Semaine trois : flux de travaux ancré dans les sources, avec citations et révision humaine. Semaine quatre : essais de sûreté et de protection des renseignements personnels, puis de bilinguisme et d’accessibilité, ainsi que de rendement. Semaine cinq : déploiement limité auprès des utilisateurs et rétroaction d’exploitation. Semaine six : rapport d’acceptation et décision de production. Chaque semaine se termine à un point de contrôle, et rien ne passe à la suite sans sa preuve.
Note
Tout point de contrôle peut arrêter le projet pilote. Un arrêt à la deuxième semaine coûte une fraction de ce que coûte un arrêt au neuvième mois. Il laisse à l’institution une décision documentée, une base de référence mesurée, un filtrage de classification et un jeu de données d’évaluation réutilisable. Inscrivez le droit d’arrêter dans les conditions du mandat.
La façon dont nous menons cet exercice est présentée sur la page du projet pilote de six semaines.
Chapitre 10
La mise en production crée une obligation d’exploitation permanente. Un budget qui couvre la construction sans couvrir cette obligation s’épuise à cette étape.
Dès le premier jour en production, cinq choses deviennent la tâche permanente de quelqu’un. Désignez ce quelqu’un avant la mise en production, des deux côtés.
Deux changements structurels comptent au-delà de la liste de vérification. Le nouveau filtrage au regard de la Directive devient un élément du contrôle des changements plutôt qu’un exercice annuel. Et, pour les institutions financières fédérales, le modèle entre dans l’inventaire des modèles avec un responsable, un calendrier de validation et des limites documentées. La ligne directrice E-23 du BSIF le prévoit. Voir l’exploitation gérée des agents (AgentOps).
Chapitre 11
Nous ne publions aucun chiffre d’économies, aucune période de récupération ni aucune allégation de rendement du capital investi, parce que nous n’en avons aucun que nous pourrions défendre. Ce que nous pouvons vous donner, c’est la structure de coûts, pour que vous la modélisiez avec vos propres chiffres.
La bonne unité est le coût par tâche terminée, c’est-à-dire une tâche qu’une personne a acceptée et utilisée. Le coût par demande ou par jeton ne la remplace pas. C’est dans l’écart entre ces mesures que les budgets dérapent : un système peu coûteux à la demande, mais qui exige trois tentatives et une escalade, n’est pas peu coûteux.
| Variable | Définition | Ce qui la fait bouger |
|---|---|---|
| Volume de contexte récupéré | Jetons de matériel source envoyés à chaque demande | Taille des segments, nombre de passages récupérés, filtrage ou non du corpus avant la récupération. Habituellement le facteur le plus important à lui seul. |
| Longueur de la sortie | Jetons générés par réponse | Format de la réponse, rédaction ou résumé par l’agent, consignes de longueur dans la requête. |
| Tours par tâche | Demandes nécessaires avant que l’utilisateur obtienne quelque chose d’utilisable | Qualité des réponses, conception de l’interface, prise en charge ou non des questions de clarification. |
| Appels d’outils et de récupération | Invocations de recherche, de bases de données et de connecteurs par tâche | Conception de l’agent, mise en cache, plan fixe ou décidé par le modèle. |
| Palier de modèle | Quel modèle traite quelle étape | Acheminement des étapes simples vers de plus petits modèles ; l’acheminement lui-même doit être évalué. |
| Reprise et abandon | Tâches payées qui n’ont rien produit d’utilisable | Ancrage dans les sources, comportement d’abstention, confiance des utilisateurs. Invisible si on ne le mesure pas. |
| Temps de révision humaine | Minutes d’effort de l’examinateur par tâche | Qualité des citations, conception de l’escalade, frictions de l’interface. Souvent plus élevé que le coût d’inférence. |
| Coût fixe de la plateforme | Capacité, environnements, surveillance, exécutions d’évaluation | Modèle d’architecture du chapitre 7. Les modèles dédiés et auto-hébergés concentrent ce coût au départ. |
| Coût d’exploitation | Exécutions de tests de non-régression, contrôle des changements, revue des accès, traitement des incidents | Fréquence des changements et profondeur des contrôles. Réel, récurrent et facile à omettre des analyses de rentabilité. |
Modélisez honnêtement votre seuil de rentabilité. Les modèles à coûts fixes ne deviennent moins chers que la tarification à l’usage qu’au-delà d’un volume soutenu que vous devriez calculer, avec un jeu d’hypothèses daté, avant de choisir. Refaites ensuite le calcul : la tarification de l’inférence a changé à plusieurs reprises, et un modèle de coûts doit porter une date pour être utilisable.
Chapitre 12
Fixez la voie d’approvisionnement avant que la conception ne soit terminée : elle contraint la portée, l’échéancier et parfois l’architecture.
Exigez des preuves plutôt que des assurances, et méfiez-vous de toute affirmation de certification, d’approbation ou d’inspection qui n’est pas accompagnée d’un document que vous pouvez lire. Le dossier de preuves du fournisseur expose ce que nous pouvons prouver aujourd’hui et ce que nous ne pouvons pas prouver. Nous l’envoyons sur demande. Le point de vue de l’acheteur se trouve sur la page destinée au gouvernement.
Pièces justificatives de travail
Huit gabarits soutiennent les douze chapitres, et chacun est décrit ici ouvertement. Les fichiers sont des documents de travail que nous envoyons sur demande ; la méthode est sur la page, pas dans un fichier.
Honnêteté
Comment nous le savons
Source
Prochaine étape
La façon la moins coûteuse d’appliquer ce guide est de noter un flux de travaux candidat selon les critères du chapitre 2 et de voir à quelle étape il échoue.
Source
Les montants en dollars de cette page sont ceux des sources ou des montants consignés, pas nos prix. Nos prix sont en dollars canadiens (CAD), TPS/TVH en sus.
Apportez le flux de travaux tel qu’il fonctionne aujourd’hui, le problème d’exploitation que vous voulez régler et la classification, si elle est connue. Amenez le parrain qui peut financer une décision, et nommez les systèmes en cause. Trente minutes, et vous conservez les notes, que nous travaillions ensemble ou non.
Lectures connexes : le filtrage EIA pour les assistants d’IA, comment évaluer un agent de connaissance, résidence des données et souveraineté, et notre modèle de contrôle.
