QiC

Charte QiC — Référentiel de contrôle proposé

QiC propose un cadre de contrôle destiné à évaluer la qualité d’une installation d’intelligence artificielle dans son contexte réel d’utilisation. L’analyse porte sur la sécurité, la fiabilité, les conditions de déploiement, la maturité de l’organisation, les coûts, la durabilité technique, l’évolutivité, la transparence et le pilotage.

L’évaluation s’appuie autant que possible sur des éléments vérifiables : configurations, tests, journaux, documentation, procédures, mesures et retours d’exploitation. Les exigences applicables dépendent du contexte, de la criticité du système, des données traitées et des usages envisagés. Ce référentiel est proposé comme grille de contrôle ; il ne signifie pas une reconnaissance officielle.

1. 01.Sécurité

   Objectif : Protéger les données, les modèles, les infrastructures et les utilisateurs contre les accès non autorisés, les fuites, les abus et les compromissions.

   Points de contrôle

   • Gestion des identités, rôles et autorisations selon le moindre privilège.
   • Protection des données en transit et au repos lorsque cela est pertinent.
   • Gestion des secrets, clés API, jetons et identifiants sans exposition dans le code ou les journaux.
   • Isolation des environnements, services et charges de travail selon les risques.
   • Mises à jour, correctifs, sauvegardes et procédures de réponse aux incidents.
   • Maîtrise des accès aux modèles, outils connectés, fichiers et services externes.
   • Vérification des risques IA : injection de prompt, divulgation de données, abus d’outils ou accès excessif aux connecteurs.

   Exemples concrets

   • Un assistant IA n’autorise chaque utilisateur qu’à consulter les documents auxquels il a déjà accès.
   • Les clés d’un fournisseur de modèles sont conservées dans un gestionnaire de secrets ou des variables d’environnement protégées, jamais dans le dépôt Git.
   • Les journaux masquent les données personnelles et secrets ; les accès administrateurs sont limités et traçables.
   • Un test vérifie qu’un prompt malveillant ne permet pas de récupérer des fichiers confidentiels.

   Éléments de preuve possibles : Matrice des habilitations, configuration des accès, résultats de tests de sécurité, politique de sauvegarde, inventaire des secrets et procédure de gestion des incidents.

2. 02.Fiabilité

   Objectif : Assurer un fonctionnement stable, des résultats suffisamment cohérents pour l’usage prévu et des performances vérifiées dans le temps.

   Points de contrôle

   • Définition des résultats attendus et des limites acceptables.
   • Tests fonctionnels, tests de non-régression et évaluations adaptées aux usages réels.
   • Mesure de la disponibilité, des temps de réponse, des erreurs et des échecs.
   • Gestion des indisponibilités des modèles, API, bases de données et services dépendants.
   • Détection des dérives de qualité ou de comportement après une mise à jour.
   • Possibilité de revenir à une version stable et de reprendre le service après un incident.
   • Prise en compte du caractère probabiliste des réponses IA : la cohérence ne garantit pas l’exactitude de chaque réponse.

   Exemples concrets

   • Un assistant documentaire est testé sur un jeu de questions représentatif, avec des réponses attendues et des critères de qualité explicites.
   • Si un fournisseur de modèles devient indisponible, l’application affiche une erreur compréhensible ou bascule vers un mécanisme de secours prévu.
   • Après un changement de modèle, une série de tests compare les résultats avec ceux de la version précédente.
   • Des alertes se déclenchent lorsque les erreurs ou temps de réponse dépassent les seuils définis.

   Éléments de preuve possibles : Rapports de tests, indicateurs de disponibilité, historique des incidents, jeux d’évaluation versionnés et procédure de retour arrière.

3. 03.Déploiement

   Objectif : Mettre en production une solution de manière maîtrisée, progressive, réversible et adaptée aux contraintes opérationnelles et réglementaires applicables.

   Points de contrôle

   • Séparation claire des environnements de développement, test et production.
   • Validation préalable des changements et plan de mise en service.
   • Déploiement progressif lorsque le risque ou l’impact le justifie.
   • Sauvegarde des données et configurations nécessaires à la reprise.
   • Plan de retour arrière et procédure de désactivation en cas de problème.
   • Vérification des dépendances, licences, conditions des fournisseurs et obligations applicables.
   • Documentation des responsabilités et opérations courantes.

   Exemples concrets

   • Une nouvelle version est testée en préproduction avec des données adaptées ou anonymisées.
   • Le déploiement d’un nouvel agent est limité à un groupe pilote avant son ouverture à tous.
   • Une mise à jour de modèle peut être annulée rapidement si elle dégrade la qualité des réponses.
   • Une procédure précise comment couper un outil IA sans rendre indisponibles les fonctions essentielles.

   Éléments de preuve possibles : Procédure de déploiement, journal des versions, plan de retour arrière, résultats de préproduction et documentation d’exploitation.

4. 04.Maturité

   Objectif : Évaluer la préparation organisationnelle, technique et méthodologique avant de choisir le périmètre et le degré d’autonomie d’une installation IA.

   Points de contrôle

   • Clarté des besoins, utilisateurs visés et bénéfices attendus.
   • Identification d’un responsable du système et des personnes qui l’exploitent.
   • Disponibilité des compétences nécessaires à l’installation, la maintenance et l’évaluation.
   • Qualité des données, processus et infrastructures préexistantes.
   • Définition de critères de réussite et d’un dispositif de retour d’expérience.
   • Identification des risques et limites avant l’élargissement des usages.
   • Progression par étapes, de l’expérimentation à une exploitation structurée.

   Exemples concrets

   • Une équipe qui découvre les agents IA commence par un assistant en lecture seule avant d’autoriser des actions métier.
   • Un projet pilote dispose d’un périmètre, d’un responsable, d’un budget, de cas de test et de critères d’arrêt explicites.
   • Avant d’automatiser le traitement de dossiers, l’organisation vérifie que les données sources sont fiables et documentées.
   • Les utilisateurs sont formés aux limites du système et savent quand demander une vérification humaine.

   Éléments de preuve possibles : Cadrage du projet, répartition des responsabilités, plan de formation, critères de succès, registre des risques et bilan du pilote.

5. 05.Maîtrise des coûts

   Objectif : Rendre les coûts visibles, prévisibles et proportionnés à la valeur obtenue sur l’ensemble du cycle de vie.

   Points de contrôle

   • Estimation des coûts de conception, intégration, hébergement, inférence et maintenance.
   • Suivi des consommations : appels API, jetons, calcul, stockage, bande passante et licences.
   • Prise en compte du coût des contrôles humains, de la supervision, des tests et du support.
   • Définition de budgets, plafonds ou alertes lorsque cela est possible.
   • Comparaison des modèles et architectures selon la qualité nécessaire, pas seulement le prix unitaire.
   • Prévision des coûts liés à la croissance des usages, aux changements de fournisseur et à la migration.
   • Mesure de la valeur obtenue au regard du coût total.

   Exemples concrets

   • Un tableau de bord distingue le coût par équipe, fonctionnalité ou millier de requêtes.
   • Les tâches simples utilisent un modèle moins coûteux ; les cas complexes vont vers un modèle plus performant si les tests le justifient.
   • Des limites de consommation et des alertes préviennent les appels en boucle ou dépenses inattendues d’un agent.
   • Une comparaison inclut l’hébergement, la maintenance et le matériel d’un modèle local, en plus du prix des API externes.

   Éléments de preuve possibles : Budget prévisionnel, relevés de consommation, coût par cas d’usage, règles de limitation et bilan coût-valeur.

6. 06.Soutenabilité technique

   Objectif : Privilégier des architectures maintenables, sobres en ressources, responsables et exploitables dans la durée.

   Points de contrôle

   • Adéquation de la puissance de calcul et de la taille des modèles au besoin réel.
   • Suivi, lorsque les moyens le permettent, de la consommation de calcul, d’énergie et de ressources.
   • Choix de composants maintenus, documentés et raisonnablement pérennes.
   • Réduction des dépendances inutiles et maîtrise des versions.
   • Possibilité de réparer, mettre à jour, remplacer ou retirer les composants.
   • Prise en compte de la durée de vie du matériel, du stockage et des données.
   • Évaluation des compromis entre performance, qualité, coût, latence et consommation.

   Exemples concrets

   • Une classification simple utilise un modèle compact si ses résultats équivalent à ceux d’un modèle beaucoup plus lourd.
   • Les résultats réutilisables sont mis en cache lorsque c’est pertinent, pour éviter des calculs répétés.
   • Les modèles, dépendances et procédures d’installation sont documentés pour permettre une reprise par une autre personne.
   • Les journaux et données temporaires ont une politique de rétention qui évite leur accumulation inutile.

   Éléments de preuve possibles : Inventaire technique, politique de maintenance, mesures de consommation disponibles, stratégie de mise à jour et plan de fin de vie.

7. 07.Évolutivité

   Objectif : Adapter la solution à l’augmentation de charge, aux nouveaux usages et aux évolutions technologiques sans refonte systématique.

   Points de contrôle

   • Architecture modulaire et séparation des responsabilités.
   • Capacité à augmenter ou réduire les ressources selon la charge.
   • Gestion des limites de débit, files d’attente et traitements concurrents.
   • Interfaces et formats d’échange documentés.
   • Possibilité de remplacer un modèle, fournisseur ou composant avec un effort maîtrisé.
   • Tests de charge et identification des principaux goulots d’étranglement.
   • Compatibilité avec les besoins futurs sans surdimensionnement prématuré.

   Exemples concrets

   • Une application sépare l’interface, l’orchestration, le stockage et l’accès aux modèles afin de faire évoluer chaque partie.
   • Un service absorbe un pic de demandes avec une file d’attente plutôt qu’un nombre illimité de traitements.
   • Un adaptateur commun permet de comparer ou remplacer des fournisseurs sans réécrire toute l’application.
   • Des tests de charge vérifient le comportement lorsque le nombre d’utilisateurs est multiplié par cinq ou dix.

   Éléments de preuve possibles : Schéma d’architecture, tests de charge, documentation des interfaces, stratégie de montée en charge et procédure de migration.

8. 08.Transparence

   Objectif : Rendre compréhensibles et traçables le fonctionnement de l’installation, ses traitements, les limites des résultats et les décisions aidées par l’IA.

   Points de contrôle

   • Information des utilisateurs sur le rôle de l’IA et ses limites.
   • Traçabilité des versions de modèles, configurations et changements significatifs.
   • Journaux proportionnés aux besoins de diagnostic et de contrôle, dans le respect de la confidentialité.
   • Identification des sources utilisées pour les documents ou données externes.
   • Explication des critères de décision lorsque c’est possible et pertinent.
   • Distinction entre faits vérifiés, estimations, hypothèses et contenu généré.
   • Documentation des limites connues, usages non prévus et situations nécessitant une validation humaine.

   Exemples concrets

   • Un assistant de recherche affiche les documents utilisés pour sa synthèse et permet de retrouver les passages pertinents.
   • L’interface indique qu’une réponse a été générée par une IA et doit être vérifiée pour les décisions sensibles.
   • Un journal retrouve la version du modèle et la configuration associées à un incident sans conserver inutilement les échanges confidentiels.
   • Une décision automatisée est accompagnée d’une explication compréhensible et, si approprié, d’un moyen de demander une revue humaine.

   Éléments de preuve possibles : Documentation utilisateur, fiches de modèles, journaux de changements, sources référencées, registre des limites et procédures de revue.

9. 09.Niveau de pilotage

   Objectif : Assurer une gouvernance effective grâce à des responsabilités identifiées, des indicateurs pertinents, des contrôles réguliers et des mécanismes de correction.

   Points de contrôle

   • Désignation des responsables métier, technique et opérationnel selon le contexte.
   • Définition d’indicateurs utiles : qualité, disponibilité, sécurité, coût, délais et incidents.
   • Seuils d’alerte et responsabilités en cas de dépassement.
   • Revue périodique des résultats, risques, accès et changements.
   • Suivi des incidents et actions correctives jusqu’à leur clôture.
   • Modalités d’escalade et de validation humaine pour les cas sensibles.
   • Réévaluation si les usages, données ou modèles évoluent.

   Exemples concrets

   • Une revue mensuelle examine les coûts, erreurs, incidents de sécurité et la satisfaction des utilisateurs.
   • Un responsable est alerté si le taux de réponses incorrectes mesuré dépasse le seuil convenu.
   • Les actions d’un agent qui modifient des données sensibles nécessitent une approbation explicite.
   • Toute évolution majeure du modèle déclenche une évaluation avant la mise en production.

   Éléments de preuve possibles : Tableau de bord, comptes rendus de revue, registre d’incidents, plan d’action, matrice de responsabilités et historique des validations.

Finalité de QiC : fournir une grille de lecture structurée pour apprécier la qualité et la maîtrise d’une installation IA, favoriser la confiance par des contrôles documentés et soutenir une amélioration continue.