Audit IA à Monaco : les 10 livrables à exiger avant de lancer un projet

Un audit IA sert à réduire l’incertitude avant la dépense

L’audit IA intervient entre une intuition — « ce processus pourrait être automatisé » — et une décision d’investissement. Son rôle est de vérifier le problème, la valeur attendue, la disponibilité des données, les contraintes et les conditions de réussite. Il doit rendre les hypothèses visibles afin que la direction puisse les accepter, les tester ou les refuser.

Un document qui énumère des dizaines d’usages génériques ne remplit pas cette fonction. Il peut inspirer, mais il ne dit pas si les demandes réelles sont assez fréquentes, si les documents sont exploitables, si l’API existe ou si une erreur créerait un risque disproportionné.

À Monaco, où des équipes compactes peuvent manipuler des informations sensibles et des dossiers à forte valeur, la précision du périmètre compte davantage que la quantité d’idées. L’audit doit produire une prochaine décision claire et proportionnée.

Livrables 1 et 2 : cartographie du processus et mesure de référence

Le premier livrable représente le flux actuel : déclencheur, acteurs, étapes, logiciels, documents, validations, exceptions et sortie attendue. Il distingue ce qui est écrit dans une procédure de ce qui se passe réellement. Sans cette carte, l’équipe risque d’accélérer une étape locale tout en créant un nouveau blocage ailleurs.

Le deuxième établit une mesure avant projet. Volume mensuel, temps de traitement, délai d’attente, taux de dossiers incomplets, nombre de ressaisies, erreurs ou reprises : quelques indicateurs suffisent s’ils décrivent le problème. Ils serviront de référence pour mesurer le pilote.

Une estimation peut être acceptable lorsqu’aucune donnée n’existe, à condition de l’indiquer et de prévoir comment la vérifier. Une promesse de ROI sans référence observable doit rester une hypothèse, pas un résultat acquis.

Livrables 3 et 4 : inventaire des données et matrice des risques

L’inventaire précise les sources, formats, volumes, responsables, qualités, droits d’accès et durées de conservation. Il indique quelles informations sont nécessaires au cas d’usage et lesquelles doivent en être exclues. Il identifie aussi les données produites par le futur système : réponses, scores, journaux, historiques ou documents dérivés.

La matrice des risques relie chaque erreur possible à sa conséquence et à son contrôle. Une mauvaise catégorie corrigée avant envoi n’a pas le même impact qu’un paiement déclenché, une information confidentielle exposée ou une décision professionnelle influencée. Le niveau d’autonomie doit suivre cette différence.

La loi n° 1.565 constitue le cadre monégasque actuel de protection des données personnelles. L’audit technique ne remplace pas l’analyse juridique, mais doit donner aux responsables et conseils les éléments factuels nécessaires : finalités, catégories de données, accès, fournisseurs, conservation et transferts envisagés.

Livrables 5 et 6 : portefeuille priorisé et fiche du premier pilote

Le portefeuille rassemble les opportunités identifiées et les classe sur une grille commune : impact, fréquence, qualité des données, complexité d’intégration, risque, effort d’adoption et possibilité de mesurer. Cette priorisation empêche le sujet le plus spectaculaire de prendre automatiquement la première place.

La fiche pilote décrit ensuite un seul périmètre : utilisateurs, entrée, sortie, sources autorisées, actions permises, validations, cas hors périmètre et durée du test. Elle fixe une taille suffisante pour produire une preuve, mais assez limitée pour pouvoir s’arrêter sans avoir construit toute l’architecture.

Un audit honnête conserve au moins quatre décisions possibles : lancer le pilote, préparer d’abord les données ou accès, résoudre le problème autrement, ou ne pas poursuivre. L’abandon argumenté d’un mauvais cas est lui aussi un retour sur investissement.

Livrables 7 et 8 : architecture cible et protocole d’évaluation

L’architecture cible montre comment circulent l’identité, les données et les actions entre les logiciels. Elle précise la source de référence, les droits de lecture et d’écriture, l’emplacement des journaux, le fournisseur de modèle, les mécanismes de reprise et les points de validation. À ce stade, un schéma compréhensible vaut mieux qu’une liste de technologies.

Le protocole d’évaluation transforme la notion de qualité en tests. Il rassemble des cas normaux, difficiles et dégradés, leurs résultats attendus, les sources de vérité et les erreurs critiques. Il mesure aussi le temps, le coût, la stabilité, les refus utiles et l’effort humain de vérification.

Le NIST AI RMF propose une démarche volontaire structurée autour de la gouvernance, de la cartographie, de la mesure et de la gestion. L’audit peut s’en inspirer pour éviter de concentrer toute l’attention sur le score moyen du modèle.

Livrables 9 et 10 : budget complet et gouvernance après lancement

Le budget distingue cadrage, prototype, intégration, préparation des données, sécurité, tests, formation et production. Il estime séparément les coûts récurrents : modèles, automatisation, stockage, hébergement, licences, supervision et maintenance. Les hypothèses de volume doivent être visibles pour comprendre comment la facture évoluera.

Le plan de gouvernance attribue les décisions : propriétaire métier, responsable technique, validation des données, gestion des accès, traitement des incidents, suivi de la qualité et autorisation des évolutions. Il précise qui peut arrêter le système et comment revenir à un mode manuel lorsque le service est indisponible.

Ces deux livrables empêchent le prototype de devenir une production par défaut. Ils montrent ce qu’il reste à financer, vérifier et organiser avant qu’un outil prometteur puisse entrer durablement dans les opérations.

La checklist pour comparer deux propositions d’audit IA

Deux offres portant le même nom peuvent couvrir des travaux très différents. Pour les comparer, demandez les personnes interrogées, le nombre de processus observés, les données analysées, le format de restitution, les ateliers inclus et la profondeur technique. Vérifiez surtout si les dix livrables sont fournis ou si certains nécessitent une phase séparée.

• Périmètre, durée, interlocuteurs et accès demandés.
• Cartographie du travail réel et mesure de la situation initiale.
• Analyse des données, droits, fournisseurs et contraintes de transfert.
• Méthode explicite de priorisation et hypothèses de valeur.
• Fiche pilote, architecture, cas de test et critères d’arrêt.
• Budget de mise en œuvre, coûts récurrents et responsabilités futures.
• Indépendance du conseil vis-à-vis des outils ou licences recommandés.

La réunion de sortie doit aboutir à une décision

La restitution n’est pas une conférence sur l’IA. Elle doit permettre à la direction, au métier, à la technique et aux personnes responsables des données de comprendre le même projet. Les désaccords, données manquantes et risques résiduels sont présentés au même niveau que les bénéfices attendus.

La décision finale porte sur le prochain engagement : objectif du pilote, responsable, budget, calendrier, accès à préparer et condition d’arrêt. Si le projet n’est pas prêt, la réunion fixe les prérequis et la date de réévaluation. Si le cas n’est pas pertinent, elle documente pourquoi.

Chez Quanta, l’audit vise cette capacité de décision. Le travail ne consiste pas à imposer un modèle, mais à construire une feuille de route limitée, compréhensible et reliée aux opérations de l’entreprise.