Presque tous les projets qu’on démarre chez Nyxora commencent par un audit. Pas parce que c’est la procédure, mais parce que la majorité des échecs que j’ai vus sur des projets IA viennent du même endroit : on a construit quelque chose d’impressionnant avant d’avoir vraiment compris le problème.

Un audit IA, chez nous, dure une à deux semaines. Ce n’est pas un audit au sens comptable du terme : on ne vient pas vérifier des chiffres, on vient comprendre un terrain. Voici ce qu’on regarde concrètement pendant ce temps-là, dans l’ordre où on le regarde.

Je précise d’entrée un point qui surprend souvent : un audit ne se termine pas toujours par une recommandation de lancer un projet. Il arrive, pas si rarement, qu’on conclue qu’aucun cas d’usage identifié ne justifie l’investissement pour l’instant, et qu’on le dise clairement plutôt que de forcer un projet pour justifier la mission. C’est aussi ce qui rend, je crois, la démarche crédible sur la durée.

1. Pas votre outillage, votre process

La première question n’est jamais « quel LLM utilisez-vous » ou « avez-vous déjà des données propres ». Elle est : comment le travail se fait-il aujourd’hui, étape par étape, avec qui, et où est-ce que ça coince. La technologie vient après. Un audit qui commence par la stack technique passe à côté du problème réel, et je l’ai vu faire assez de fois pour m’en méfier systématiquement.

Concrètement, ça veut dire s’asseoir avec les personnes qui font le travail au quotidien, pas seulement avec leur manager. La personne qui traite les tickets support sait des choses que le directeur des opérations ignore, et inversement. Un audit qui ne parle qu’aux décideurs rate la moitié de l’information utile.

Cette étape prend en général deux à trois jours sur les deux semaines, et c’est rarement du temps perdu même quand elle ne débouche pas immédiatement sur une découverte spectaculaire : elle installe une relation de confiance avec les équipes de terrain, sans laquelle la suite de l’audit récolterait des réponses polies plutôt que des réponses honnêtes.

2. Où part le temps humain

On cherche systématiquement les tâches répétitives et bien définies : un poste ouvert depuis longtemps parce que personne ne veut le faire, une équipe qui traite le même type de demande à la chaîne, des rapports refaits à la main chaque semaine. C’est là que se trouve le premier cas d’usage réaliste, pas dans l’idée la plus ambitieuse listée en réunion.

J’ai un réflexe qui revient dans presque chaque audit : demander à voir le dernier rapport hebdomadaire produit à la main, celui que quelqu’un recopie chaque semaine depuis trois sources différentes dans un tableur. Ce document, souvent présenté avec un peu de gêne comme « le truc pas très sexy qu’on fait tous les lundis », est presque toujours le meilleur point de départ qu’on trouvera pendant tout l’audit.

3. Les signaux qu’on cherche activement

Certains signaux reviennent avec une régularité frappante d’une entreprise à l’autre, et on les cherche activement dès le premier jour. Un poste de type Data Scientist ou AI Engineer resté ouvert plus de deux mois indique un budget déjà arbitré et une charge réelle non couverte. Des prises de parole publiques sur l’IA sans mise en œuvre concrète en interne révèlent souvent un écart entre l’intention affichée et la capacité réelle à agir. Un volume élevé de tickets support répétitifs, ou des avis clients qui pointent systématiquement vers la lenteur du service, indiquent un point de friction opérationnelle mesurable et déjà documenté par les clients eux-mêmes.

Ces signaux ne sont pas des curiosités qu’on note en passant : ce sont littéralement ce qu’on va chercher en priorité, parce qu’ils indiquent un problème déjà reconnu par l’organisation, avec un budget ou une urgence déjà associée. C’est beaucoup plus rapide à faire avancer qu’un problème qu’il faut d’abord convaincre l’entreprise d’avoir.

Le meilleur signal qu’on peut trouver dans un audit n’est pas une opportunité IA. C’est une tâche que personne n’aime faire, qui revient chaque semaine, et dont on peut mesurer le coût actuel.

4. Ce que livre concrètement un audit

À la fin des deux semaines, vous recevez trois choses : une cartographie claire de vos processus candidats, deux ou trois cas d’usage priorisés selon leur fréquence, la disponibilité des données et le risque, et un chiffrage réaliste de ce que coûterait chacun à mettre en place. Pas un rapport de quarante pages qui prend la poussière : un document qu’on peut utiliser en comité de direction la semaine suivante, avec des chiffres qu’on peut défendre.

  • Cartographie des processus candidats, classés par impact et faisabilité
  • 2 à 3 cas d’usage priorisés avec estimation de gain et de coût
  • Une recommandation claire sur la suite : PoC, automatisation, ou rien pour l’instant
  • La liste des signaux qui ont motivé chaque priorisation, pour que la décision reste vérifiable, pas juste affirmée

5. Pourquoi deux semaines, pas deux mois

Un audit trop long finit par devenir un projet en soi. On garde volontairement ce format court : assez de temps pour comprendre le terrain, pas assez pour se perdre dedans. Si un sujet mérite plus d’investigation, il devient une étape suivante clairement identifiée, pas une extension silencieuse de l’audit qui gonfle sans jamais aboutir à une décision.

Cette contrainte de temps n’est pas qu’une question d’efficacité pour nous : elle protège aussi le client d’un travers courant, celui de l’audit qui s’éternise parce que chaque nouvelle découverte ouvre une nouvelle question. Deux semaines forcent à trancher, à prioriser, et à livrer une recommandation exploitable plutôt qu’une exploration sans fin.

6. Ce qui arrive quand on saute cette étape

J’ai repris plusieurs projets qui avaient démarré directement sur un développement, sans cette phase de cadrage. Le schéma se répète : l’équipe technique construit une solution élégante sur un problème mal défini, le système fonctionne parfaitement en démo, et personne ne l’utilise trois mois plus tard parce qu’il ne correspond pas à la vraie façon dont le travail se fait sur le terrain. Reprendre ces projets coûte presque toujours plus cher que de faire l’audit dès le départ.

7. Ce qui change selon le type d’entreprise

Un audit ne se déroule pas exactement de la même façon selon qui est en face. Dans une PME ou une ETI qui n’a pas d’équipe IA interne, on passe plus de temps à cartographier les processus existants qu’à discuter de faisabilité technique : le vrai travail est de rendre visible ce qui se fait déjà, souvent de façon informelle et dispersée entre plusieurs personnes.

Dans une startup qui vient de lever des fonds, avec une équipe produit déjà en place, l’audit prend une tournure différente : les développeurs savent construire, mais manquent de repères sur ce qu’un LLM ou un agent peut raisonnablement faire aujourd’hui. On y passe plus de temps à cadrer ce qui est réaliste, à écarter les idées trop ambitieuses pour un premier projet, qu’à chercher où se trouve le besoin. Dans une agence qui répond à une demande de ses propres clients sans avoir de practice IA affichée, l’angle change encore : l’audit sert autant à définir une offre reproductible qu’à qualifier un premier projet précis.

8. Ce que j’aurais aimé savoir avant mon premier audit

Le premier audit que j’ai mené seule, avant même de fonder Nyxora, portait sur un service client débordé qui pensait avoir besoin d’un chatbot. J’ai passé la première semaine à essayer de comprendre leur outil de ticketing plutôt que leur équipe, persuadée que la technologie révélerait le problème. Elle ne l’a pas fait : c’est en m’asseyant deux heures avec trois agents support, sans ordinateur ouvert, que j’ai compris que 60% des tickets répétaient les cinq mêmes questions, jamais correctement documentées nulle part.

Ce que j’en ai gardé, et que j’applique depuis systématiquement : le temps passé loin des outils et proche des gens qui font le travail est presque toujours plus rentable que le temps passé à explorer une stack technique. Ce n’est pas une leçon intuitive quand on vient d’un profil technique, et c’est probablement la plus utile que j’ai apprise sur le terrain plutôt que dans un livre.

En résumé

Un audit IA ne sert pas à vous convaincre de faire de l’IA. Il sert à savoir, avec des chiffres, si ça vaut le coup, où commencer, et ce que ça va réellement coûter. C’est la porte d’entrée la plus honnête qu’on connaisse pour démarrer un projet qui tient la route, et c’est pour ça qu’on continue à commencer par là, même quand un client arrive déjà convaincu de vouloir « un agent » ou « un chatbot ».