Quand on travaille plusieurs années sur un produit, on finit par ne plus vraiment le voir. On en connaît les écrans par cœur, les raccourcis, les exceptions, les contraintes historiques qu’on a fini par accepter. Une étape inutile devient normale. Une formulation ambiguë ne choque plus personne. Une fonctionnalité oubliée continue d’exister parce qu’elle a toujours été là.
Ce n’est pas propre au logiciel. C’est vrai des sites, des procédures commerciales, du support, des documents internes, des offres. L’habitude est une excellente alliée pour avancer vite — et une mauvaise conseillère quand il s’agit de repérer ce qui cloche. Plus on connaît un produit, moins on est capable d’en détecter les incohérences.
Le regard extérieur est précieux, mais rare
On connaît tous la valeur d’un œil neuf. Un consultant, un nouvel arrivant, parfois un client posent une question toute simple qui remet en cause des années d’habitudes :
- Pourquoi faut-il passer par cet écran pour faire ça ?
- Pourquoi cette information est-elle demandée deux fois ?
- Pourquoi trois outils différents pour la même tâche ?
- Pourquoi cette fonctionnalité est-elle encore proposée alors que plus personne ne l’utilise ?
Le problème de ce regard extérieur, c’est qu’il est occasionnel. Il arrive quand un nouveau collaborateur débarque, quand on paie un audit, quand un client s’agace. Le reste du temps, on avance avec nos angles morts.
L’IA peut jouer ce rôle-là, mais régulièrement, et à grande échelle.
C’est la bascule que je trouve la plus intéressante. Pas « l’IA écrit du code plus vite », mais « l’IA regarde ce que je ne regarde plus. » À condition de bien s’y prendre.
Lui donner autre chose que le code
Un audit pertinent ne se limite jamais au dépôt Git. Le code raconte comment le produit est fait ; il ne dit pas s’il tient encore ses promesses, ni si les gens s’en servent, ni ce qu’il coûte.
Pour qu’une IA voie ce que nous ne voyons plus, il faut lui donner le contexte que nous avons en tête sans jamais l’écrire : des captures d’écran, des parcours utilisateurs, des tickets de support, des statistiques d’usage, des coûts, des conversations commerciales, des documentations, des retours clients, des journaux d’erreurs.
En croisant ces sources, l’IA fait apparaître des incohérences qu’aucune équipe ne voit dans son périmètre isolé, parce que chacun ne regarde qu’un bout : une fonctionnalité coûteuse qui génère du support et que presque personne n’utilise, une page qui promet ce que le produit ne fait plus, un même besoin traité de trois façons différentes dans trois applications.
Chercher les contradictions, pas un avis
L’erreur la plus courante, c’est de demander à l’IA « que penses-tu de notre produit ? ». La question est trop large, la réponse sera générique et polie — exactement ce dont on n’a pas besoin.
Un audit utile se commande par des missions précises, presque des enquêtes :
- Identifie les fonctionnalités dupliquées entre nos applications.
- Compare notre promesse commerciale au comportement réel du produit.
- Repère les étapes sans valeur dans ce parcours.
- Liste les coûts sans usage mesurable.
- Trouve les sujets de support récurrents qu’on pourrait supprimer à la source.
Formulée ainsi, l’IA cesse d’être un commentateur et devient un outil d’enquête. Elle ne cherche plus à me faire plaisir ; elle cherche des contradictions. Et elle en trouve.
Je vais être concret, avec notre propre stack. Un audit outillé de notre site vitrine a exhumé, en une passe, ce que des mois d’habitude nous avaient rendu invisible :
- Une brique de journalisation morte depuis des mois, toujours déclarée en dépendance dans le projet — plus appelée nulle part, mais jamais retirée.
- Un fichier de configuration d’un ancien framework, vestige de notre stack précédente, resté dans le dépôt bien après la migration. Personne ne l’ouvrait plus, donc personne ne le voyait.
- Une clé d’API documentée comme variable d’environnement, mais morte côté runtime : plus aucun code ne la consommait. Elle traînait dans la doc comme une promesse sans objet.
- Une fonctionnalité retirée sans redirection des anciennes URLs. Le contenu avait disparu, mais rien n’avait été mis en place pour rediriger proprement les visiteurs et les moteurs. Une incohérence restée invisible jusqu’à l’audit.
Aucune de ces trouvailles n’était visible à l’œil nu. Aucune n’était grave prise isolément. Mais aucune non plus n’aurait été trouvée en relisant le code « avec attention » : il aurait fallu que quelqu’un doute précisément de ces points-là. Ce ne sont pas nos yeux qui les ont débusquées, ce sont des audits outillés — un audit de dépendances, un audit de site, un audit de fonctionnalités, une vérification de couverture d’indexation — qui ont passé le produit au crible sans le confort de l’habitude.
Le multimodal change la donne
Longtemps, auditer un produit voulait dire lire son code ou ses logs. Aujourd’hui, une IA peut regarder un écran comme un utilisateur le regarde : une capture, un parcours, une interface. Elle lit ce qui est affiché, pas seulement ce qui est écrit dans le dépôt.
Ça ouvre un champ entier. On peut lui demander de comparer ce qu’une page promet à ce que le produit fait réellement. De repérer une formulation qui a vieilli. De signaler qu’un bouton mène à une fonctionnalité qu’on croyait retirée. Le décalage entre le discours et le réel, celui qu’on ne voit plus parce qu’on a écrit les deux, une IA multimodale le voit tout de suite.
Un audit permanent plutôt qu’exceptionnel
Traditionnellement, on audite quand un problème devient visible. C’est déjà tard. Le coût est là, la dette aussi, et on découvre après coup ce qui couvait depuis des mois.
Avec l’IA, l’audit peut devenir continu au lieu d’être un événement. Chaque semaine, un agent analyse les nouveaux tickets, les erreurs, les coûts, les changements récents, et signale les tendances plutôt que d’attendre la crise. Il ne remplace pas le jugement humain — il augmente simplement la probabilité qu’un humain regarde au bon endroit, au bon moment.
C’est un renversement de logique. On ne se demande plus « quand faut-il auditer ? » mais « qu’est-ce que le regard extérieur a remonté cette semaine ? ». L’audit passe du statut d’exception coûteuse à celui de routine peu chère. Et une routine, contrairement à un audit ponctuel, ne dépend plus de la volonté qu’on a, ou pas, de se remettre en cause un jour donné.
Accepter de découvrir des choses inconfortables
Reste la partie la plus difficile, et elle n’est pas technique.
Un audit vraiment utile ne se contente pas de confirmer que le travail est bon. Il peut montrer qu’une fonctionnalité qu’on a défendue n’est pas utilisée. Qu’un investissement n’a pas produit la valeur attendue. Qu’une brique qu’on a construite avec soin mériterait d’être supprimée.
La difficulté n’est plus de trouver l’incohérence — l’IA sait le faire. C’est d’accepter de remettre en cause, ou de supprimer, ce qu’on a construit. L’IA aide à voir ; elle ne décide pas à notre place si nous sommes prêts à regarder.
Et c’est peut-être là que le dirigeant a un vrai rôle. Pas commander l’audit — ça, on peut l’outiller et l’automatiser. Mais créer les conditions pour que ses conclusions soient entendues plutôt que rangées. Un regard extérieur permanent n’a de valeur que si l’organisation accepte, de temps en temps, de ne pas aimer ce qu’il montre.
Et vous — qu’est-ce que votre produit vous cache aujourd’hui, simplement parce que vous le connaissez trop bien pour le voir ?