Audit IA à Paris

L’audit part des processus réels, des données disponibles et des contraintes. L’idéation produit des idées ; l’audit produit des décisions étayées.

La différence se voit au livrable. Un atelier d’idéation rend une liste de cas d’usage classés par enthousiasme, sans savoir lesquels sont faisables avec vos données. Un audit rend, pour chaque cas envisagé : l’état réel des données nécessaires, la charge de mise en œuvre, le gain estimé avec son hypothèse, le risque réglementaire, et une recommandation de faire ou de ne pas faire.

C’est cette dernière ligne qui manque le plus souvent, et c’est celle qui a de la valeur. Un audit qui recommande de ne rien automatiser sur trois cas sur quatre a fait son travail.

En pratique : deux à cinq jours selon le périmètre, avec des entretiens métier, une inspection des données et un chiffrage. Le résultat vous appartient même si vous ne poursuivez pas avec nous, et il sert de base à une mise en concurrence si vous le souhaitez.

Les personnes qui connaissent le processus, celles qui détiennent les données et celles qui décident. Sans ces trois points de vue, l’audit reste théorique.

Celui qui connaît le processus est indispensable et souvent oublié : il sait ce qui se passe réellement, y compris les contournements et les exceptions que la procédure officielle ignore. C’est dans ces exceptions que se trouvent les raisons pour lesquelles une automatisation échoue.

Celui qui détient les données dit ce qui existe, sous quelle forme, depuis quand et avec quelle fiabilité. Son avis évite les projets fondés sur des données qu’on croyait complètes.

Celui qui décide fixe le critère de réussite et arbitre le niveau de risque acceptable. Sans lui, l’audit produit une recommandation que personne ne peut valider.

Compter trois à six entretiens d’une heure. Nous demandons ces noms au démarrage, avec leurs disponibilités — c’est la contrainte de calendrier la plus fréquente et la moins anticipée.

Par l’analyse de leur complétude, de leur fraîcheur, de leur cohérence, de leur accessibilité et de leur adéquation au cas d’usage envisagé.

Cinq mesures, dans cet ordre. La complétude : quel pourcentage des enregistrements portent réellement le champ nécessaire. La fraîcheur : à quelle date remonte la dernière mise à jour, et quelle part est périmée. La cohérence : un même fait est-il écrit de la même manière — les variantes d’orthographe d’un nom de client suffisent à faire échouer un rapprochement. L’accessibilité : peut-on extraire ces données par un moyen programmable, ou faut-il une intervention manuelle. Et l’adéquation : les données décrivent-elles ce qu’on veut prédire ou retrouver.

Cette dernière question est la plus décisive et la plus négligée. Un historique volumineux mais qui ne contient pas l’information à apprendre ne sert à rien, quelle que soit sa taille.

Le constat habituel : les données existent, elles sont moins bonnes qu’on le croyait, et un chantier de nettoyage précède l’IA. Nous le disons plutôt que de construire sur du sable.

Il propose une estimation étayée par des hypothèses explicites, plutôt qu’une promesse chiffrée sans fondement mesurable.

La méthode : identifier le volume traité, le temps consacré par unité, le coût de ce temps, la part que l’automatisation peut réellement prendre, et le taux d’erreur acceptable. Chaque terme est une hypothèse, chaque hypothèse est écrite, et le résultat est une fourchette.

Ce qui rend ces calculs souvent faux ailleurs : compter le gain sur cent pour cent des cas alors que les exceptions représentent vingt à quarante pour cent et restent manuelles ; oublier le coût de vérification, qui subsiste même quand la production est automatisée ; et ignorer le coût récurrent des modèles, qui se facturent à l’usage.

Nous présentons donc deux scénarios, prudent et favorable, avec les hypothèses qui les séparent. Un client peut ainsi juger sur ce qui lui paraît réaliste plutôt que sur notre optimisme.

Il arrive que le calcul conclue à l’absence de gain. C’est un résultat utile, et il coûte quelques jours plutôt que quelques mois.

Non. Le choix technique vient après la définition du problème, des données et des exigences de qualité, de coût et de confidentialité.

L’ordre inverse est fréquent et coûteux : une organisation souscrit une plateforme, puis cherche quoi en faire. Le résultat habituel est un outil peu utilisé et un abonnement annuel.

Ce qui doit précéder le choix : le problème formulé en termes de décision ou de tâche, les sources autorisées, le niveau de qualité attendu et comment il sera mesuré, les contraintes de confidentialité — vos données peuvent-elles sortir de l’Union européenne —, et le budget récurrent acceptable.

Ces éléments déterminent le choix presque mécaniquement. Une contrainte forte de confidentialité oriente vers un modèle hébergé en Europe ou déployé chez vous. Un volume élevé et une tâche simple orientent vers un petit modèle, nettement moins cher. Une tâche de raisonnement complexe justifie un grand modèle et son coût.

Et ce choix doit rester réversible : nous concevons les systèmes pour que le modèle soit remplaçable.

Oui. L’analyse porte sur les données, les résultats, les usages réels, les risques et la conformité, avec des recommandations concrètes.

Le point de départ est l’usage réel, qui diffère souvent de l’usage prévu : qui s’en sert, combien de fois par semaine, pour quelle tâche, et que font les utilisateurs du résultat. Un assistant consulté trois fois par mois pose un problème d’adoption avant un problème technique.

Vient ensuite la qualité, mesurée plutôt que ressentie : nous constituons un jeu de cas représentatifs avec les réponses attendues, et nous mesurons. Beaucoup de systèmes en production n’ont jamais été évalués ainsi, et le résultat surprend dans les deux sens.

Puis les risques : les sources accessibles au système sont-elles celles qu’on croit, les données sensibles sont-elles exclues, les résultats sont-ils traçables, et une personne peut-elle contester une décision.

Et la conformité, en particulier la classification du système au regard du règlement européen, qui détermine les obligations. Un système utilisé en ressources humaines ou en évaluation de personnes a des exigences que la plupart ignorent.

Par l’identification du rôle joué, de la catégorie de risque du cas d’usage et des obligations correspondantes en matière de documentation, de transparence et de contrôle humain.

Deux questions se posent d’abord. Quel rôle tenez-vous : fournisseur si vous mettez un système sur le marché sous votre nom, déployeur si vous l’utilisez dans votre activité. La majorité des entreprises sont déployeurs, avec des obligations plus légères mais réelles.

Et dans quelle catégorie tombe l’usage. La plupart des cas d’entreprise — assistant documentaire, aide à la rédaction, classement de demandes — relèvent du risque limité, avec une obligation principale de transparence : dire à l’utilisateur qu’il parle à un système. Certains usages basculent en risque élevé, notamment le recrutement, l’évaluation du personnel, l’accès au crédit ou à des services essentiels. Là, les obligations sont substantielles.

L’audit établit cette classification par écrit, avec ce qu’elle implique et le calendrier d’application. Ce n’est pas un avis juridique et nous le disons : sur un cas à risque élevé, nous recommandons de faire valider par un conseil.

Vous disposez d’un diagnostic et d’un plan priorisé. La suite peut être menée par vos équipes, par Novatis ou par un autre prestataire.

Le livrable est conçu pour cela : il décrit chaque cas d’usage retenu avec son périmètre, ses données, ses critères d’acceptation, ses risques et sa charge estimée. C’est un document qui permet de mettre en concurrence, et nous l’assumons — un audit dont le résultat n’est utilisable que par son auteur n’est pas un audit.

La suite recommandée est presque toujours la même : un premier cas d’usage, petit, sur un périmètre où l’erreur est visible et peu coûteuse, avec une évaluation chiffrée avant d’élargir. Nous déconseillons les programmes qui ouvrent quatre chantiers simultanés, parce qu’aucun n’atteint le niveau de qualité nécessaire à l’adoption.

Il arrive que la recommandation soit de ne rien faire pour l’instant — données insuffisantes, processus en cours de refonte, gain incertain. Dans ce cas l’audit a évité une dépense, et c’est le meilleur résultat qu’il pouvait produire.