Audit IA

Les projets d’IA échouent rarement sur la technique : ils échouent parce que le sujet choisi n’était pas le bon, parce que les données n’existaient pas sous une forme exploitable, ou parce que l’outil visé ne s’ouvrait pas. L’audit traite ces trois questions avant la première ligne de code.

Public concerné

À qui s’adresse un audit IA

Les situations où il a du sens

L’audit est utile quand une gêne réelle est identifiée (temps perdu, délais, réponses répétitives, ressaisies) sans que l’on sache quelle brique d’IA y répond. Il l’est aussi quand plusieurs idées se disputent le même budget : le document final sert alors à les classer plutôt qu’à les additionner.

• Vous avez testé des assistants en usage individuel et cherchez à passer à un usage collectif structuré.
• Vous hésitez entre un chatbot IA sur le site, l’automatisation du traitement des documents ou un assistant interne.
• Un prestataire vous a proposé une solution et vous voulez un regard indépendant avant de signer.
• Un premier essai n’a rien donné et vous voulez comprendre ce qui a bloqué avant de recommencer.

Les situations où il ne sert à rien

Si votre besoin est déjà cadré, si vous savez quelle tâche automatiser et sur quelles données, l’audit ne fera que retarder le chantier : passez directement à la conception, décrite sur la page développement IA. Si votre demande porte sur la visibilité de votre site dans les moteurs et les assistants, c’est l’audit SEO et GEO qui traite ce périmètre.

Il n’a pas davantage de sens quand la difficulté est organisationnelle avant d’être technique : un processus que personne ne suit de la même façon d’un service à l’autre ne devient pas automatisable parce qu’on y ajoute un LLM.

Grille d’analyse

Les cinq dimensions examinées

L’examen porte toujours sur les mêmes cinq axes, parce que ce sont eux qui déterminent si un projet tient.

Dimension	Ce que l’on regarde	Ce que cela détermine
Les tâches et leur répétitivité	Qui fait quoi, à quelle fréquence, selon quelles règles, avec quelles exceptions	Le gain potentiel et la stabilité du résultat attendu
L’état des données	Où vivent les informations, sous quel format, avec quel niveau de propreté et de mise à jour	La faisabilité d’un assistant qui répond à partir de vos contenus
L’ouverture technique des outils	Présence d’une API, de webhooks, d’exports, de droits d’accès exploitables	Le coût d’intégration et le niveau d’automatisation atteignable
Les compétences internes	Qui pilote, qui contrôle les sorties, qui reprend la main en cas d’erreur	La capacité à exploiter et à maintenir ce qui sera livré
Les contraintes de confidentialité	Nature des données manipulées, obligations du secteur, règles internes	Les traitements à exclure et les précautions à inscrire au cahier des charges

Les tâches et leur répétitivité

On recense les tâches réellement exécutées, pas celles décrites dans les procédures. Une tâche intéressante est fréquente, suit des règles explicitables et produit un résultat vérifiable. Une tâche rare, ou dont personne ne sait dire ce qu’est une bonne réponse, fera un mauvais premier chantier, comme le rappelle la page automatisation des tâches web.

L’état des données

C’est le point qui fait le plus souvent basculer un projet. On examine les sources une par une (fichiers bureautiques, base du site, outils de gestion, messageries, documents scannés) et, pour chacune : format, volume, fraîcheur, doublons, structure exploitable ou non. Cet état des lieux indique si une approche de type RAG ou une base de connaissances est envisageable, ou s’il faut d’abord ranger.

L’ouverture technique des outils en place

Un outil qui expose une API et des webhooks se connecte ; un outil fermé impose des contournements coûteux et fragiles. On vérifie ce qui est disponible, avec quels droits, et si un serveur MCP peut exposer ces outils à vos assistants.

Les compétences internes

Un dispositif d’IA se conduit. On identifie qui saura formuler les demandes, relire les sorties et signaler les dérives. Quand cette compétence manque, l’audit le signale et oriente vers une formation IA plutôt que vers un développement immédiat.

Les contraintes de confidentialité

On liste les catégories de données que le projet toucherait et les règles qui s’y appliquent chez vous. L’audit ne délivre pas d’avis juridique et ne certifie aucune conformité : il repère les points à trancher avec vos responsables et à écrire noir sur blanc, dans la logique exposée sur la page sécurité et conformité IA.

Méthode de travail

Le déroulé en trois temps

Les modalités pratiques, le format et le coût de l’audit se précisent au premier échange, en fonction du périmètre à couvrir.

Usages du document

Ce que l’audit permet de décider

Un audit se juge à la qualité des décisions qu’il rend possibles. À sa lecture, une direction doit pouvoir arbitrer sans revenir vers son auteur.

• Lancer un chantier précis, dont le périmètre est écrit et chiffrable.
• Reporter un chantier tant qu’une condition n’est pas remplie (données à structurer, outil à changer, règle interne à écrire).
• Former les équipes avant d’outiller, quand la marge de progression tient d’abord à l’usage.
• Comparer des propositions extérieures sur une base commune, au lieu de comparer des promesses.
• Ne rien faire pour le moment, en connaissance de cause.

La dernière décision est légitime. Si aucune tâche ne présente un gain suffisant, si les données ne sont pas prêtes et si aucun outil ne s’ouvre, la conclusion honnête est de s’abstenir et de réexaminer plus tard. Un audit qui aboutit là a fait son travail : il a évité une dépense sans contrepartie.

Limites du périmètre

Ce que l’audit n’est pas

• Ce n’est pas une démonstration d’outils ni un panorama du marché : aucun produit n’y est classé.
• Ce n’est pas un développement : rien n’est mis en production pendant l’audit, la réalisation vient après.
• Ce n’est pas un audit de sécurité ni un avis juridique, même si les points sensibles sont signalés.
• Ce n’est pas un audit de visibilité : les moteurs et les assistants relèvent du pôle SEO et GEO.
• Ce n’est pas un engagement de résultat : le document éclaire une décision, il ne garantit pas un gain.

Vos interrogations

Questions fréquentes

Faut-il préparer quelque chose avant l’audit ?

Rien d’obligatoire. Deux choses aident : la liste des outils utilisés au quotidien et le nom des personnes à interroger dans chaque service.

L’audit fonctionne-t-il si nos données sont en désordre ?

Oui, et c’est une des situations où il est le plus utile. Le désordre n’empêche pas l’examen : il devient l’un de ses résultats, avec le détail de ce qu’il faudrait reprendre pour ouvrir des usages aujourd’hui hors d’atteinte.

Sommes-nous obligés de confier la suite au même intervenant ?

Non. Le livrable est rédigé pour être exploitable par n’importe quelle équipe, interne ou externe. Un périmètre bien écrit permet d’ailleurs de demander plusieurs devis comparables, comme l’explique la page tarifs.

L’audit couvre-t-il aussi notre site web ?

Il couvre le site en tant qu’outil : ce qu’on peut y lire et y écrire, la structure des contenus, les usages possibles pour vos visiteurs comme pour vos équipes. En revanche, sa visibilité reste hors périmètre.

Que se passe-t-il si l’audit conclut qu’il n’y a rien à faire ?

Vous obtenez la liste des raisons et les conditions qui feraient évoluer ce constat. C’est un résultat utilisable : il ferme un débat interne et fixe le moment où la question méritera d’être reposée.