P8 DCO E

Exploitation, monitoring & amélioration

La phase P8 correspond au régime permanent du cycle de vie d’une solution IA : exploitation, monitoring, maintien en conformité et amélioration continue. Cette phase mobilise l’ensemble des compétences du DCO E — gérer le portefeuille (E1), surveiller l’utilisation (E2), surveiller les exigences de conformité (E3), améliorer en continu (E4). À la différence des phases précédentes, qui s’inscrivent dans une logique projet à durée déterminée, la phase P8 est continue : elle s’étend sur la durée d’utilisation de la solution, qui se compte typiquement en années.

Le rôle de l’AIBS en phase P8 évolue significativement par rapport aux phases de projet. La responsabilité opérationnelle quotidienne incombe aux fonctions d’exploitation (ICT Service Management) et aux responsables produits métier ; l’AIBS exerce une responsabilité de pilotage stratégique du portefeuille IA et de garantie du respect des exigences cadrées en amont. Selon le profil de qualification, l’AIBS gère le portefeuille avec l’aide de spécialistes en ce qui concerne différents facteurs (sécurité, qualité, rentabilité, durabilité, éthique) et le respect de la conformité pertinente.

Une caractéristique structurante de la phase P8 tient à la dimension temporelle des risques IA. Une solution IA peut se dégrader silencieusement par drift des données ou des concepts, sans incident apparent : les prédictions deviennent moins précises, les biais évoluent, la conformité aux nouvelles exigences réglementaires se distend. Sans dispositif de surveillance approprié, ces dégradations passent inaperçues jusqu’à un événement révélateur — incident utilisateur, audit, contestation. Le pire risque IA est silencieux ; l’investissement en monitoring est l’instrument de sa détection.

Le livrable principal de la phase n’est pas un document ponctuel mais un dispositif permanent : tableaux de bord de monitoring, processus de revue périodique, boucles d’amélioration continue. La qualité de ce dispositif conditionne directement la durabilité de la valeur créée par la solution. Une solution IA non monitorée ne se contente pas de stagner, elle se dégrade.

Méthode pas-à-pas

Voici le déroulé concret de la phase, étape par étape :

1. Établir et tenir à jour la cartographie du portefeuille IA (compétence E1)

• Recenser exhaustivement les solutions IA en exploitation dans l’organisation
• Pour chaque solution : description, finalité métier, périmètre d’utilisation, responsable produit, date de mise en service, version, dépendances techniques
• Cartographier les dépendances entre solutions IA, systèmes ICT, flux de données et processus métier
• Tenir à jour la cartographie selon une fréquence définie (typiquement mensuelle ou trimestrielle)
• Coordonner avec l’ICT Service Management pour l’intégration dans les outils de gestion du SI

2. Définir les critères de surveillance multi-dimensions (compétence E2)

• Définir avec les parties prenantes les dimensions de surveillance pertinentes : exploitation technique, sécurité, qualité fonctionnelle, rentabilité, durabilité, risques, éthique
• Pour chaque dimension, définir des indicateurs mesurables et des seuils d’acceptabilité
• Identifier les sources de données nécessaires aux mesures et les modalités de collecte
• Convenir des fréquences de surveillance : continue pour les KPIs techniques critiques, périodique pour les KPIs métier, ponctuelle pour les audits ciblés
• Définir les modalités d’alerte : seuils de déclenchement, destinataires, processus de réponse

3. Mettre en œuvre le tableau de bord de monitoring

• Concevoir le tableau de bord avec les fonctions d’exploitation et les responsables produits
• Structurer en couches : KPIs techniques (disponibilité, latence, erreurs), KPIs ML (performance modèle, drift), KPIs métier (usage, valeur produite), KPIs conformité, KPIs financiers
• Définir les vues différenciées selon les destinataires : vue opérationnelle pour ICT, vue métier pour responsables produits, vue stratégique pour pilotage du portefeuille
• Industrialiser la collecte des données et la mise à jour automatique des indicateurs
• Définir les rituels de revue : quotidien pour incidents critiques, hebdomadaire pour exploitation, mensuel pour pilotage métier, trimestriel pour pilotage stratégique

4. Surveiller le drift des données et des modèles

• Mettre en œuvre avec le data scientist la détection de data drift : évolution de la distribution des données d’entrée par rapport au jeu d’entraînement
• Mettre en œuvre la détection de concept drift : évolution de la relation entre données d’entrée et variable cible
• Définir les seuils d’alerte : niveau de drift à partir duquel un retraining est déclenché ou une investigation est initiée
• Distinguer les drifts attendus (saisonnalité, évolution prévisible) des drifts inattendus (signal d’un changement structurel)
• Documenter les événements de drift et les actions menées (retraining, ajustement, abandon)

5. Surveiller les exigences de conformité (compétence E3)

• Identifier les changements de gouvernance externe ou interne pouvant affecter les solutions IA : évolutions réglementaires, nouvelles normes sectorielles, modifications de la stratégie ou de la gouvernance interne
• Analyser et évaluer l’impact des changements sur chaque solution IA, en mobilisant les responsables produits et les spécialistes
• Conduire des revues périodiques de conformité (typiquement annuelles ou semestrielles) sur l’ensemble du portefeuille
• Identifier les écarts et planifier les mesures de mise en conformité
• Documenter les revues et les actions correctives pour traçabilité

6. Animer la boucle d’amélioration continue (compétence E4)

• Recueillir et analyser les retours d’utilisation par enquêtes utilisateurs, observations, mesures qualitatives
• Identifier les potentiels d’amélioration : ergonomie, performance, fonctionnalités, intégration
• Constituer un backlog d’amélioration priorisé selon la valeur attendue et l’effort nécessaire
• Coordonner avec les spécialistes la mise en œuvre des améliorations retenues
• Évaluer l’impact des améliorations et communiquer les progrès aux parties prenantes

7. Conduire les revues périodiques du portefeuille

• Organiser des revues trimestrielles ou semestrielles couvrant l’ensemble du portefeuille IA
• Présenter aux décideurs : performance globale du portefeuille, indicateurs clés par solution, conformité, incidents marquants, axes d’amélioration
• Identifier les solutions à fort enjeu (alerte sur un indicateur, opportunité d’évolution majeure) pour traitement spécifique
• Identifier les solutions à abandonner ou à transformer (utilité décroissante, coût disproportionné, obsolescence technologique)
• Documenter les décisions prises et les actions à mener

8. Gérer les évolutions et les fins de vie

• Pour chaque évolution majeure d’une solution : conduire une revue d’impact, mobiliser les compétences appropriées, valider l’engagement, documenter
• Pour chaque fin de vie d’une solution : organiser le décommissionnement, gérer les transferts de données, archiver les documentations, communiquer aux utilisateurs
• Documenter les enseignements tirés du cycle de vie complet de chaque solution pour bénéfice des futurs projets
• Maintenir la cohérence du portefeuille au fil des évolutions

Outils — mode d’emploi détaillé

Cartographie du portefeuille IA

Mode d’emploi :

• Référentiel structuré listant l’ensemble des solutions IA en exploitation
• Pour chaque solution : identifiant unique, description fonctionnelle, périmètre d’utilisation, responsable produit, sponsor, date de mise en service, version courante
• Caractéristiques techniques : approche IA (ML supervisé, GenAI, etc.), modèles utilisés, infrastructure, sources de données
• Caractéristiques organisationnelles : utilisateurs cibles et effectifs, processus métier concernés, services supports mobilisés
• Caractéristiques de conformité : classification AI Act le cas échéant, statut DPIA, exigences sectorielles applicables, dates de revue
• Indicateurs synthétiques : santé technique, niveau d’adoption, niveau de performance fonctionnelle, statut de conformité
• Visualisation : tableau de bord exécutif, cartographie des dépendances, fiches détaillées par solution
• Mise à jour selon une fréquence définie, généralement mensuelle ou trimestrielle

Variantes : Cartographie sur tableur pour PME avec quelques solutions. Référentiel intégré au CMDB de l’organisation pour les grands comptes. Cartographie spécialisée IA pour organisations avec un grand portefeuille.

⚠ Piège classique

Cartographie réalisée une fois puis non maintenue. Sans mise à jour régulière, le référentiel perd sa valeur de pilotage. La désignation d’un responsable de la cartographie et l’inscription dans les rituels de gouvernance sont essentielles.

Tableau de bord de monitoring IA

Mode d’emploi :

• Dispositif consolidant les indicateurs de surveillance pour une solution donnée
• Couche 1 — KPIs techniques : disponibilité du service, latence d’inférence, taux d’erreurs, débit, utilisation des ressources
• Couche 2 — KPIs ML : performance du modèle (précision, rappel selon le type de problème), data drift, concept drift, distribution des prédictions
• Couche 3 — KPIs métier : usage effectif (utilisateurs actifs, fréquence), atteinte des objectifs fonctionnels (gain de temps, qualité, satisfaction)
• Couche 4 — KPIs conformité : statut DPIA, dates de prochaines revues, incidents de conformité, demandes d’exercice des droits des personnes concernées
• Couche 5 — KPIs financiers : coûts d’exploitation, ROI réalisé vs business case, écart budgétaire
• Vues différenciées selon les destinataires : opérationnel temps réel, métier hebdomadaire, stratégique mensuel ou trimestriel
• Alertes automatiques sur les seuils définis : disponibilité dégradée, drift significatif, écart de KPI métier

Variantes : Outils techniques : Grafana, Tableau, Power BI, solutions MLOps spécialisées (MLflow, Weights & Biases). Niveau d’investissement adapté à la criticité de la solution.

⚠ Piège classique

Tableau de bord surchargé d’indicateurs techniques sans hiérarchisation. La règle d’usage : un tableau de bord exécutif tient sur un écran, les détails sont accessibles en un ou deux clics.

Détection de drift (data drift, concept drift)

Mode d’emploi :

• Data drift — évolution de la distribution des données d’entrée par rapport au jeu d’entraînement
• Méthodes de détection : tests statistiques (KS, chi-deux), distance entre distributions (KL, EMD), monitoring de chaque feature
• Concept drift — évolution de la relation entre données d’entrée et variable cible : la même configuration d’entrée produit une cible différente
• Méthodes de détection : surveillance de la performance du modèle dans le temps, détection de retournements de tendance, mesure de l’erreur sur jeux de test récents
• Définition des seuils d’alerte : niveaux de drift acceptables, niveaux nécessitant investigation, niveaux déclenchant retraining automatique
• Distinction entre drift attendus (saisonnalité, événements connus) et drift inattendus (signaux d’un changement structurel)
• Rôle de l’AIBS : compréhension conceptuelle suffisante, mise en place et exploitation des mécanismes par les spécialistes data science

Variantes : Surveillance manuelle périodique pour solutions à faible volume. Surveillance continue automatisée pour solutions critiques. Approches statistiques classiques ou modernes (modèles de détection d’anomalies).

⚠ Piège classique

Réaction automatique de retraining sans investigation des causes. Un drift peut signaler un changement structurel justifiant une révision du modèle plutôt qu’un simple retraining sur les données récentes.

Revue périodique de conformité

Mode d’emploi :

• Cycle de revue formalisé sur le portefeuille IA, généralement annuel avec déclencheurs événementiels intermédiaires
• Inventaire des exigences applicables : LPD, AI Act, exigences sectorielles, gouvernance interne, normes ISO
• Pour chaque solution : statut de conformité par exigence, écarts identifiés, mesures correctives planifiées, prochaine revue
• Identification des évolutions : nouvelles exigences réglementaires, modifications de gouvernance interne, retours d’incidents, observations d’audit
• Analyse d’impact des évolutions sur chaque solution, avec mobilisation des spécialistes appropriés (DPO, juriste, conformité, sécurité)
• Plan d’action consolidé : mesures de mise en conformité, échéances, responsables, ressources
• Reporting au comité de direction et aux instances de gouvernance appropriées
• Déclencheurs événementiels intermédiaires : nouvelle réglementation, incident significatif, alerte d’audit, évolution majeure d’une solution

Variantes : Revue allégée annuelle pour PME. Revue approfondie semestrielle pour organisations à fort enjeu réglementaire. Audit externe complémentaire selon les exigences sectorielles.

⚠ Piège classique

Revue formelle conduite sans articulation avec les évolutions opérationnelles. La conformité ne se vérifie pas une fois par an et s’oublie le reste du temps ; elle se construit dans la continuité de l’exploitation.

Boucle de feedback utilisateurs

Mode d’emploi :

• Dispositif structuré de recueil et de traitement des retours utilisateurs
• Canaux : enquêtes périodiques (NPS, CSAT), focus groups thématiques, observations directes, retours via outils de support, feedback intégré à la solution
• Fréquence : continue pour les retours intégrés, périodique pour les enquêtes (mensuelle, trimestrielle, semestrielle)
• Traitement : analyse qualitative et quantitative, identification des thèmes récurrents, hiérarchisation
• Actions : ajustements rapides pour les irritants simples, inscription au backlog d’amélioration pour les évolutions structurantes, communication aux utilisateurs sur les actions menées
• Bouclage : information régulière des utilisateurs sur la prise en compte de leurs retours et les améliorations apportées
• Indicateurs : volume de retours, taux de réponse aux enquêtes, évolution de la satisfaction dans le temps

Variantes : Boucle légère pour solutions à faibles volumes. Boucle structurée pour solutions à enjeux d’adoption. User Research formalisé pour solutions à transformation majeure.

⚠ Piège classique

Recueil de retours sans bouclage vers les utilisateurs. Sans communication sur les actions menées, le canal de feedback s’éteint progressivement et la qualité des retours se dégrade.

Backlog d’amélioration

Mode d’emploi :

• Liste structurée des améliorations identifiées, priorisée selon la valeur attendue et l’effort nécessaire
• Pour chaque élément : description, source (retour utilisateur, observation, alerte technique, évolution réglementaire), bénéfice attendu, effort estimé, priorité
• Catégorisation : amélioration fonctionnelle, ajustement technique, mise en conformité, évolution majeure
• Priorisation collégiale avec sponsor et responsables produits, selon les méthodes appropriées (matrice valeur-effort, MoSCoW, RICE)
• Mise en œuvre par cycles d’amélioration (typiquement trimestriels) ou intégration aux évolutions majeures
• Suivi : éléments en cours, terminés, abandonnés ; bilan périodique de la dynamique d’amélioration

Variantes : Backlog géré dans un outil dédié (Jira, Azure DevOps) pour grandes organisations. Tableur partagé pour PME. Articulation avec le backlog produit existant le cas échéant.

⚠ Piège classique

Backlog en croissance continue sans capacité de mise en œuvre. La dynamique de priorisation et d’abandon des éléments obsolètes est aussi importante que l’enrichissement initial.

Cas type

Bonnes pratiques observées

Recommandations issues de la pratique professionnelle :

• Le pire risque IA est silencieux. Une solution non monitorée peut se dégrader pendant des mois sans incident apparent, jusqu’à un événement révélateur. L’investissement en monitoring est l’instrument de prévention de ces dégradations.
• La distinction entre data drift et concept drift est conceptuellement importante. Le data drift signale un changement dans les données entrantes ; le concept drift signale un changement dans la relation entre données et cible. Les réponses appropriées diffèrent.
• Le rôle de l’AIBS en phase P8 ne consiste pas à exploiter techniquement les solutions, mais à piloter le portefeuille et à garantir la cohérence des dispositifs de surveillance, de conformité et d’amélioration.
• La cartographie du portefeuille IA constitue un actif stratégique pour l’organisation. Sans cartographie tenue à jour, les décisions stratégiques (priorisation des évolutions, gestion des dépendances, anticipation des risques) reposent sur une vision partielle.
• Les KPIs de monitoring se déclinent en couches : techniques, ML, métier, conformité, financiers. Une surveillance limitée aux KPIs techniques manque les dérives métier ; une surveillance limitée aux KPIs métier manque les dégradations techniques.
• Les revues périodiques de conformité ne se substituent pas à la veille réglementaire continue. Une nouvelle exigence majeure (par exemple un AI Act suisse) appelle une revue d’impact ad hoc, sans attendre le cycle annuel.
• Les solutions IA ont des cycles de vie qui se comptent en années, mais des évolutions technologiques significatives peuvent intervenir en quelques mois. Un équilibre est à trouver entre stabilité d’exploitation et capacité de modernisation.
• La boucle de feedback utilisateurs perd son efficacité sans bouclage. Communiquer aux utilisateurs les améliorations apportées en réponse à leurs retours maintient la qualité du canal sur la durée.
• Le backlog d’amélioration appelle une dynamique de priorisation et d’abandon. Un backlog en croissance continue sans capacité de mise en œuvre devient un signal de désengagement plutôt qu’un actif d’amélioration.
• La fin de vie d’une solution IA est une étape à part entière, à anticiper et à gérer. Un décommissionnement non planifié laisse des données orphelines, des dépendances cachées et des risques de conformité résiduels.
• Les enseignements tirés du cycle de vie complet d’une solution IA bénéficient aux futurs projets. La capitalisation systématique en fin de vie ou aux jalons majeurs alimente la maturité de l’organisation.
• L’AIBS exerce en phase P8 une vigilance stratégique sur les évolutions de l’environnement : nouvelles technologies susceptibles de dépasser les solutions existantes, évolutions réglementaires structurantes, changements dans les attentes des utilisateurs.

Erreurs fréquentes — et leur antidote

❌ Erreur : Absence de monitoring après la mise en production

✓ Antidote : Inscription du dispositif de monitoring comme livrable obligatoire de la phase P7, avec validation explicite avant transition vers l’exploitation.

❌ Erreur : Monitoring limité aux KPIs techniques

✓ Antidote : Surveillance multi-couches : technique, ML, métier, conformité, financière. Chaque couche apporte une vision complémentaire et nécessaire.

❌ Erreur : Absence de surveillance du drift

✓ Antidote : Mise en place avec le data scientist d’un mécanisme de détection automatique du data drift et du concept drift, avec seuils d’alerte et procédure de réponse.

❌ Erreur : Cartographie du portefeuille IA réalisée une fois puis non mise à jour

✓ Antidote : Désignation d’un responsable de la cartographie et inscription de la mise à jour dans les rituels périodiques (mensuels ou trimestriels).

❌ Erreur : Conformité vérifiée annuellement sans veille réglementaire continue

✓ Antidote : Dispositif de veille réglementaire (LPD, AI Act, sectoriel) avec analyse d’impact systématique des évolutions identifiées sur le portefeuille.

❌ Erreur : Boucle de feedback utilisateurs sans bouclage vers les utilisateurs

✓ Antidote : Communication régulière aux utilisateurs sur les retours pris en compte et les améliorations apportées. La transparence maintient la qualité du canal.

❌ Erreur : Backlog d’amélioration en croissance continue sans dynamique de mise en œuvre

✓ Antidote : Cycles trimestriels de priorisation et de mise en œuvre, avec revue des éléments anciens (réorientation, abandon, fusion).

❌ Erreur : Retraining automatique sans investigation des causes du drift

✓ Antidote : Procédure d’investigation systématique avant retraining : analyse de la nature du drift (saisonnier, structurel, anomalie), validation par le data scientist, décision argumentée.

❌ Erreur : Absence de plan de fin de vie pour les solutions vieillissantes

✓ Antidote : Inscription de la fin de vie dans le cycle de vie de chaque solution, avec déclencheurs anticipés (obsolescence technologique, baisse d’utilité, alternative supérieure).

FAQ — questions fréquentes

Quelle est la fréquence appropriée du retraining d’un modèle ?

La fréquence dépend de la nature du problème et de la rapidité d’évolution des données. Pour des données stables (par exemple classification documentaire), un retraining annuel peut suffire. Pour des données très évolutives (par exemple recommandation de contenus), un retraining mensuel ou hebdomadaire peut être nécessaire. La règle d’usage : déclencher le retraining sur signal de drift plutôt que sur calendrier fixe, et réévaluer la fréquence pertinente tous les six à douze mois.

Comment articuler les rôles de l’AIBS et de l’ICT Service Management en phase P8 ?

L’ICT Service Management assure la responsabilité opérationnelle quotidienne : disponibilité, performance technique, gestion des incidents, conformité aux SLA. L’AIBS assure la responsabilité de pilotage du portefeuille IA : cohérence stratégique, surveillance multi-dimensions, conformité réglementaire, amélioration continue. Les deux fonctions interagissent par les rituels de gouvernance et le partage du tableau de bord de monitoring.

Que faire si une solution IA en exploitation perd progressivement son utilité ?

Trois options sont à évaluer. Option 1 — réinvestissement : analyser les causes de la perte d’utilité (évolution des besoins, dégradation technique, alternative supérieure) et investir pour rétablir la pertinence. Option 2 — transformation : pivoter la solution vers un nouveau périmètre fonctionnel ou de nouveaux utilisateurs. Option 3 — fin de vie : décommissionner la solution et libérer les ressources. La décision relève d’une analyse coût-bénéfice argumentée et d’une validation par le sponsor.

Comment gérer une évolution réglementaire structurante (par exemple un AI Act suisse) ?

Cinq étapes successives. Étape 1 — analyse d’impact : identifier les solutions du portefeuille concernées par les nouvelles exigences. Étape 2 — évaluation des écarts : pour chaque solution concernée, mesurer l’écart par rapport aux nouvelles exigences. Étape 3 — plan de mise en conformité : actions, échéances, responsables, ressources. Étape 4 — mise en œuvre coordonnée avec les responsables produits et les fonctions de conformité. Étape 5 — vérification de l’effectivité de la mise en conformité.

Comment intégrer la durabilité dans la surveillance des solutions IA ?

La durabilité se décline sur plusieurs dimensions. Empreinte carbone : mesurer la consommation énergétique de l’inférence et du retraining, comparer aux alternatives (modèles plus légers, fréquence ajustée). Pérennité technologique : surveiller la dépendance à des fournisseurs ou technologies dont l’avenir est incertain. Compétences : maintenir la capacité de l’organisation à comprendre, faire évoluer ou décommissionner la solution. Ces dimensions s’intègrent au tableau de bord de monitoring.

Quelle est la fréquence appropriée de revue du portefeuille IA ?

Les rythmes recommandés combinent plusieurs niveaux. Revue technique opérationnelle : hebdomadaire ou mensuelle, par les fonctions d’exploitation. Revue produit : mensuelle, par responsable produit avec l’AIBS. Revue stratégique du portefeuille : trimestrielle, par l’AIBS avec le sponsor et le comité de direction. Revue de conformité : annuelle systématique, complétée par des revues événementielles.

Comment évaluer la performance globale du portefeuille IA d’une organisation ?

L’évaluation porte sur plusieurs dimensions. Valeur produite : ROI cumulé du portefeuille par rapport aux investissements, cohérence avec la stratégie. Maturité opérationnelle : fiabilité, conformité, qualité de la surveillance. Capacité d’évolution : taux d’amélioration continue, capacité d’introduction de nouvelles solutions. Risques : niveau de dette technique, dépendances externes, vulnérabilités identifiées. Une revue annuelle structurée du portefeuille au comité de direction synthétise ces dimensions.

Pour aller plus loin

• « Designing Machine Learning Systems » — Chip Huyen (Ouvrage) — Référence sur la mise en exploitation et le monitoring des systèmes ML
• « Machine Learning Engineering » — Andriy Burkov (Ouvrage) — Pratiques d’ingénierie pour le cycle de vie complet
• MLOps Maturity Model — Microsoft (Référentiel) — Cadre d’évaluation de la maturité opérationnelle ML
• « Building Machine Learning Pipelines » — Hapke, Nelson (Ouvrage) — Approche pipeline pour l’exploitation
• Google MLOps : Continuous Delivery and Automation Pipelines for ML (Article technique) — Cadre conceptuel de référence sur le MLOps
• ITIL 4 — Service Operation (Référentiel) — Bonnes pratiques de gestion des services en exploitation

Synthèse de la phase

Questions clés à se poser

• Comment la solution s’inscrit-elle dans le portefeuille IA global ?
• Quels KPIs de surveillance (technique, métier, conformité, éthique) ?
• Quelle fréquence de revue de conformité (LPD, AI Act, gouvernance interne) ?
• Comment recueillir les retours et identifier les améliorations ?
• Quand re-trainer le modèle / faire évoluer la solution ?

Outils mobilisables

• Cartographie du portefeuille IA
• Tableau de bord de monitoring (technique + métier)
• Détection de drift (data drift, concept drift)
• Revue périodique de conformité
• Boucle de feedback utilisateurs
• Backlog d’amélioration

Spécialistes à solliciter

L’AIBS coordonne — il convient de mobiliser les expertises suivantes à cette phase :

• ICT Service Management (run technique)
• Data Scientist (drift, retraining)
• DPO et juriste (conformité périodique)
• Métier (utilité long terme)

Livrable type

Tableau de bord de monitoring + revues périodiques + plan d’amélioration

Critères go / no-go pour passer à la phase suivante

• Les KPIs de monitoring sont définis et collectés ?
• Les revues de conformité sont planifiées ?
• Le processus d’amélioration continue est en place ?

⚠ Piège classique

Mettre en prod et passer à autre chose : sans monitoring, la dérive du modèle, l’évolution réglementaire ou la perte d’utilité passent inaperçues. Le pire risque IA est silencieux.

Boussole AIBS — Manuel méthodologique non officiel pour le brevet fédéral d’AI Business Specialist.

Sources : Profil de qualification AIBS v15.04.2025 · Annexe directives FAAIB v1.01 · Document modules FAAIB v2.0 · Règlement examen v3.0 (mars 2026)