Du prototype d’IA à la production : une liste de vérification pour les équipes québécoises

1. Confirmer la décision produit avant d’améliorer le modèle

Nommez la personne qui utilisera la capacité, la tâche ou la décision qui changera et l’amélioration observable qui rendrait le système valable. « Utiliser l’IA générative » n’est pas un résultat produit. « Réduire le temps nécessaire pour trouver, comparer et traiter des documents clients approuvés tout en conservant les sources » peut être évalué.

Comparez le processus assisté par l’IA avec des options plus simples. Une meilleure recherche, des règles déterministes, une modification du processus, un produit existant ou une petite intégration pourraient offrir moins de risque. Le plan doit expliquer pourquoi l’IA est justifiée et quels faits feraient changer la recommandation.

• Personne utilisatrice et tâche précises
• Processus actuel et points de rupture
• Comportement cible et utilité mesurable
• Solutions sans IA et options d’achat examinées
• Responsable de l’adoption et du changement opérationnel

2. Dessiner la limite des données et des permissions

Dressez la liste de chaque source que le système lit, génère, conserve ou transmet à un fournisseur de modèles. Indiquez qui peut y accéder, comment les limites entre clients ou espaces sont appliquées, ce qui quitte l’organisation et combien de temps les requêtes, réponses, journaux et évaluations sont gardés.

Au Québec, un système qui touche des renseignements personnels peut entraîner des obligations de gouvernance, de politique, de consentement ou d’évaluation des facteurs relatifs à la vie privée selon le contexte. Le flux technique doit être défini assez tôt pour qu’une validation juridique et de confidentialité puisse encore influencer l’architecture.

• Source, propriétaire, sensibilité et usage permis
• Contrôle de l’identité, du rôle, de l’espace et de la multitenance
• Paramètres de conservation et d’entraînement du fournisseur
• Région de traitement et chaîne de sous-traitance
• Suppression, rectification, exportation et piste d’audit
• Interdiction d’envoyer des demandes ou données clients vers un service d’IA non approuvé

3. Évaluer le vrai processus, pas quelques requêtes impressionnantes

Constituez des tâches représentatives, des cas difficiles, les sources attendues, les résultats inacceptables et les situations où une personne doit réviser ou reprendre le travail. Séparez la qualité du modèle, de la recherche, des outils, de la logique applicative et de l’interface afin de pouvoir diagnostiquer une erreur.

La mesure utile dépend du travail : exactitude des sources, précision et rappel, taux de complétion, temps de révision, escalade, réussite de la tâche ou autre signal. Fixez le seuil minimal et la personne responsable avant la mise en ligne.

4. Concevoir les erreurs comme un état normal

Les modèles expirent, les fournisseurs limitent les requêtes, les sources vieillissent, la recherche retourne le mauvais contexte et les réponses peuvent sembler certaines tout en étant fausses. Le produit doit prévoir le comportement : nouvelle tentative, repli, résultat partiel, refus, révision humaine ou chemin déterministe sécuritaire.

N’enrobez pas l’incertitude dans une prose convaincante. Montrez les sources lorsque la réponse dépend d’un corpus contrôlé. Faites confirmer les actions importantes. Limitez les permissions des outils et conservez une trace inspectable lorsque le processus l’exige.

5. Intégrer le système qui entoure l’IA

La valeur en production dépend souvent davantage de l’intégration que de la formulation de la requête. Identité, permissions, état du processus, règles d’affaires, notifications, écritures de données, historique, accessibilité et expérience mobile déterminent si la capacité est réellement utilisable.

Traitez l’IA comme un composant de l’application. Documentez ses contrats. Gardez une validation déterministe après la génération lorsqu’un résultat doit respecter un schéma ou une règle. Utilisez le traitement asynchrone lorsque la latence risquerait de bloquer le travail.

6. Établir le budget d’exploitation

Estimez le coût selon le volume, les modèles, la taille des entrées, la recherche, les appels d’outils, les reprises, la mise en cache et l’évaluation. Ajoutez limites et alertes avant l’arrivée du trafic. Une capacité abordable en démonstration peut devenir coûteuse si chaque action déclenche plusieurs appels.

Surveillez la latence, les réussites, les erreurs du fournisseur, les replis, les résultats d’évaluation et le coût par tâche utile. Ne conservez pas les requêtes ou réponses par défaut simplement parce qu’un outil d’observabilité le permet; la journalisation doit respecter la limite des données.

7. Attribuer les responsabilités et déployer progressivement

Nommez les responsables des changements de modèle, des évaluations, des incidents, de la qualité des sources, du soutien, des questions de confidentialité et de la rétroaction. Documentez aussi comment désactiver la fonction de façon sûre et qui peut le décider.

Commencez avec un groupe contrôlé dont le processus peut être observé. Comparez avec l’ancienne méthode. Élargissez seulement lorsque les faits le justifient. Le vrai jalon n’est pas « la fonction est livrée », mais « le système possède une boucle d’exploitation responsable ».

• Plan de mise en ligne et de retour arrière
• Seuils de surveillance et d’alerte
• Responsables produit et technique nommés
• Chemin de soutien et d’escalade
• Calendrier de régression des évaluations
• Processus de rétroaction et de changement
• Date de décision pour élargir, revoir ou retirer

La porte de production

Avant le lancement, l’équipe devrait répondre à quatre questions : quel résultat utile le système crée-t-il? À quelles données et à quelle autorité a-t-il accès? Comment savons-nous qu’il réussit ou échoue? Qui l’exploite et l’améliore après la mise en ligne?

Si ces réponses restent vagues, l’initiative demeure un prototype, même si la démonstration est spectaculaire.