Vous avez une application qui tourne, des utilisateurs qui s'en servent, et une facture qui tombe chaque mois. Et vous n'avez aucune idée de ce qu'il y a dedans. Votre prestataire vous dit que tout va bien. Votre équipe vous dit que chaque petite modification prend 3 semaines. Et vous, vous devez décider : continuer, changer de prestataire, refaire, ou arrêter.
Vous ne pouvez pas décider sans regarder à l'intérieur. C'est ce que fait un audit technique. Pas un audit de plusieurs mois avec une armée de consultants, et pas un audit de sécurité non plus. Un regard expérimenté, généraliste et exhaustif sur votre application, qui se termine par un document que vous pouvez mettre entre les mains de n'importe quel prestataire.
Votre décision engage des dizaines de milliers d'euros. Le développement informatique coûte cher, et l'IA a déplacé les budgets vers des projets plus gros et plus rapides plutôt que de les réduire. Un audit se chiffre en quelques milliers d'euros. Votre calcul est vite fait, à condition que l'audit regarde les bonnes choses.
Quand un audit technique d'application vaut le coup
Personne ne commande un audit par curiosité. On le commande quand une décision coûteuse dépend de ce qu'il y a dans le code. Voici 3 situations réelles, avec ce qui a été trouvé et ce que ça a changé :
Vous payez des licences pour un outil que vous pourriez posséder
Coût de fonctionnement- La situation
- Une PME du transport payait chaque année un éditeur pour un outil métier qui suivait ses opérations. L'audit devait dire avec quelles technologies digitaliser ce processus au meilleur coût.
- Le constat
- Refaire l'outil couvrait 90 % du besoin réel, beaucoup plus vite et pour beaucoup moins cher que la somme des licences à venir. Les 10 % restants n'étaient utilisés par personne.
- La suite
- L'entreprise a arrêté de payer l'éditeur et a fait construire sa propre version. Les coûts de fonctionnement ont baissé dès la première année.
Votre agence a construit trop gros, et vous ne le voyez pas
Architecture surdimensionnée- La situation
- Chez DI&Care, une entreprise de santé dont l'étude de cas est publiée sur ce site, une agence avait développé l'application en microservices : des dizaines de petits programmes indépendants qui se parlent entre eux, là où un seul programme bien organisé suffisait.
- Le constat
- L'audit a montré un système surdimensionné pour le besoin, et une dépendance croissante à des briques propriétaires, des composants que seule l'agence savait faire tourner et qui ne servaient pas les intérêts du client. Le code restait chez l'agence.
- La suite
- Tout n'a pas pu être repris, faute d'avoir la main sur le code. Mais l'audit a permis de dire stop aux services propriétaires et de réduire ce qui pouvait l'être. L'agence a fermé 2 ans plus tard.
L'application a été codée avec l'IA, et elle marche
Dette fonctionnelle- La situation
- Un dirigeant avait fait construire un outil d'estimation par des étudiants outillés par un assistant de programmation. L'outil fonctionnait, et l'adoption traînait.
- Le constat
- Pas mal de dette fonctionnelle, des écrans et des règles que personne ne sait plus justifier. Et 3 sujets jamais abordés : une IA qui répond avec confiance quand elle ne sait pas, une indexation de documents faite au hasard, et aucun cloisonnement entre l'environnement de développement et celui des utilisateurs.
- La suite
- L'audit a mis ces 3 sujets sur la table avant qu'ils ne coûtent, et a donné un ordre pour les traiter.
Un point commun relie ces situations : dans chacune, le client pensait avoir un problème de coût ou d'adoption, et l'audit a trouvé un problème de structure. Ce n'est jamais le symptôme qui coûte cher, c'est sa cause. Le troisième cas est détaillé dans le décryptage sur les outils internes construits avec l'IA.
Ce qu'un audit de code demande avant de commencer
Un audit ne commence pas par le code. Il commence par les accès, parce qu'une application n'est jamais seule : elle dépend de serveurs, de fournisseurs, de mots de passe, et de gens. Les 6 choses à rassembler avant le premier jour :
- Les accès aux serveurs, à l'hébergement et à la base de données.
- Les accès aux fournisseurs dont l'application dépend : envoi de mails, paiement, cartographie, modèles d'IA.
- La façon dont les secrets sont gérés : mots de passe, clés d'accès, qui les connaît et où ils sont rangés.
- Le processus de mise en production, c'est-à-dire la façon dont une modification arrive jusqu'à vos utilisateurs : qui livre, comment, et ce qui se passe quand ça casse.
- La liste des technologies utilisées, et pourquoi elles ont été choisies.
- L'objectif du projet, écrit en 3 lignes, pour juger si l'application est trop grosse ou trop petite pour lui.
On apprend déjà beaucoup en rassemblant cette liste. Si personne chez vous ne sait où sont les clés d'accès, vous avez un premier risque. Si le processus de mise en production tient dans la tête d'une seule personne, vous en avez un deuxième. Si votre prestataire met 3 semaines à donner un accès en lecture, vous avez une information sur votre prestataire.
Ne sautez pas la dernière ligne, l'objectif du projet : c'est la plus souvent oubliée. Elle est pourtant celle qui permet de juger le reste : une application est trop grosse ou trop petite par rapport à quelque chose. Sans l'objectif, l'audit se contente de décrire. Avec l'objectif, il peut juger.
Les 4 signaux d'un audit technique qui disent 80 % du projet
Un audit n'a pas besoin d'outils lourds ni de grilles à 200 critères. Rien qu'en mettant la tête dans le code et en cherchant les principaux problèmes, on comprend 80 % d'un projet. Les 4 signaux, dans l'ordre où ils se regardent :
- La dette technique et la structure
- Est-ce que le code a l'air à peu près propre, bien structuré, documenté ? Pas ligne par ligne : à l'échelle du projet. Un projet où on trouve les choses là où on les attend peut être repris ; un projet où chaque morceau est rangé à un endroit différent devra être réécrit.
- La gestion produit
- Est-ce qu'il y a un backlog, la liste de ce qui reste à faire ? Est-ce que ce qui a été fait est documenté ? Est-ce que l'historique des modifications est propre, avec une façon de travailler lisible ? Une application sans historique est une application dont personne ne sait plus pourquoi elle est comme ça.
- L'IA, si elle est présente
- Comment elle est faite. Soit sans méthode, un appel au modèle d'IA avec une consigne écrite à la va-vite, soit avec une vraie indexation de vos documents, pour que l'IA réponde à partir de vos contenus et pas de mémoire, ce que les développeurs appellent le RAG. Est-ce qu'on voit ce qu'elle répond, à qui, et combien ça coûte ? Une IA dont personne ne surveille les réponses est une IA dont les erreurs remontent par vos clients.
- La production
- Est-ce qu'il y a des problèmes de performance évidents, des choix d'architecture qui ne tiennent pas debout, des coûts qui ne se justifient pas ? Et est-ce que tout ce qui fait tourner une production est là ? Des journaux d'erreurs lisibles, des alertes qui remontent quelque part en cas d'erreur, un moyen de revenir en arrière, et plusieurs environnements pour ne pas tester chez vos utilisateurs.
Le quatrième signal, la production, est celui qui surprend le plus les dirigeants, parce qu'il ne parle pas de code. Un site e-commerce construit en microservices, avec des dizaines de programmes indépendants, coûte cher à faire tourner et cher à faire évoluer, alors qu'une solution sur étagère aurait couvert le besoin. Ce n'est pas une faute de code, c'est un défaut de pragmatisme, et il se voit dans la facture d'hébergement avant de se voir dans le code.
Le troisième signal, l'IA, est nouveau et il grossit. Une IA branchée sans méthode marche en démonstration et se met à inventer en production. Vous devez pouvoir répondre à 3 questions :
- D'où vient ce qu'elle répond ?
- Qui voit ses réponses ?
- Combien elles coûtent ?
Si personne chez vous ne peut répondre, l'audit classe le sujet en critique, quelle que soit la qualité du reste.
Ce que l'audit technique ne regarde pas, et ce qu'il laisse à d'autres
Un audit qui prétend tout couvrir ne couvre rien. Le périmètre honnête d'un audit technique généraliste s'arrête à 3 endroits, à connaître avant de commander l'audit :
- Le style du code, ligne par ligne
- Depuis que l'IA écrit une grande partie du code, la façon d'écrire dépend de l'outil qui génère, et elle est devenue homogène. Ce qui compte n'est plus comment une fonction est écrite, mais si elle existe 3 fois sous 3 formes différentes, si elle est testée, et si le métier est isolé du reste.
- La sécurité en profondeur
- Un audit technique regarde les accès, les secrets et les évidences. Il ne remplace pas un audit de sécurité, avec tests d'intrusion, fait par une société spécialisée. Si l'audit technique voit un trou, il le signale et vous oriente.
- La donnée avancée
- La qualité des données, les traitements complexes, les pipelines : c'est le métier d'un data engineer. L'audit technique dit si la donnée est au bon endroit et si elle est protégée, pas si elle est juste.
Le premier point a changé en 2 ans. Avant, un audit de code passait du temps sur la façon d'écrire : les conventions, la lisibilité, les commentaires. Aujourd'hui, l'IA écrit la majorité du code et son style est homogène. Ce qui reste discriminant tient en 3 questions :
- Est-ce qu'il y a des tests ?
- Est-ce que la même chose a été construite plusieurs fois, de plusieurs façons ?
- Est-ce que la logique de votre métier est isolée du reste, ou mélangée partout ?
La duplication est le signe le plus fiable. Une règle métier implémentée 3 fois sous 3 formes, c'est une règle qui donnera 3 résultats différents le jour où quelqu'un en modifie une seule. Et la logique métier mélangée à tout le reste, c'est une application qu'on ne peut pas reprendre sans tout comprendre.
Comment on lit une application en 2026
Personne ne lit à la main une application de plusieurs centaines de milliers de lignes. Les assistants de programmation, Claude Code en tête, permettent d'explorer un projet entier, de repérer les duplications, de cartographier les dépendances et de poser des questions au code. Un audit technique en 2026 s'appuie sur ces outils, avec des séquences de questions préparées, et il s'adapte à chaque nouvelle génération d'outils.
Mais l'outil ne juge pas, il montre, et le jugement vient de l'expérience. Avoir vu ce que devient une application en microservices 3 ans plus tard. Avoir repris un projet dont l'historique était vide. Avoir été appelé un vendredi soir parce qu'aucune alerte n'existait. L'audit ouvre aussi le projet dans un environnement de développement classique, pour comprendre l'architecture comme le ferait la personne qui va le reprendre.
Méfiez-vous d'un rapport généré d'un bloc par une IA, avec 80 points de vigilance non hiérarchisés. Un vrai audit se reconnaît à ce qu'il tranche : 5 risques critiques, pas 80 remarques.
Le livrable d'un audit technique : 20 à 50 pages, une seule structure
Vous recevez un document partagé, de 20 à 50 pages selon l'application, livré en 2 semaines environ. Il s'ouvre sur une vue d'ensemble des risques, chacun avec sa criticité et le domaine où il s'applique : structure, production, produit, IA, sécurité. Puis chaque risque est décrit avec la même structure, toujours la même, en 4 blocs :
- Le risque, en langage non technique
- Une phrase que votre direction financière comprend sans vous. « Si le serveur tombe un vendredi soir, personne n'est prévenu avant lundi. »
- Le constat exact
- Ce qui a été vu, où et comment, avec le nom du fichier, la configuration ou la capture. Pas une impression, mais une preuve que votre prestataire peut vérifier.
- L'origine du problème
- Pourquoi c'est comme ça : souvent un choix raisonnable à l'époque et jamais revu, parfois un choix qui servait le prestataire plus que vous.
- Les conséquences
- Ce qui se passe si vous ne faites rien : en argent, en temps, en risque pour vos clients. C'est cette ligne qui décide de la criticité.
De chaque risque découlent des recommandations, et refusez celles qui arrivent sans charge ni bénéfice, parce que ce sont des vœux. Chacune tient en 4 lignes :
- L'action à faire
- Une action précise, jamais un souhait : « mettre en place une alerte sur les erreurs serveur », et non « améliorer la supervision ».
- Le bénéfice
- Ce que vous gagnez concrètement, rapporté au risque que la recommandation couvre.
- La charge de travail
- La charge est donnée en jours, avec une fourchette, pour que vous puissiez comparer un devis à cette ligne.
- La complexité de mise en œuvre
- Ce qui peut se faire un mardi après-midi, et ce qui demande d'arrêter le service ou de prévenir vos utilisateurs.
Le document se termine sur un plan d'action et une enveloppe budgétaire pour résoudre ce qui a été identifié. L'enveloppe est présentée avec plusieurs options quand c'est pertinent : avec l'auditeur, avec des freelances, avec un prestataire externe, ou en interne. Vous repartez avec un plan de remise à niveau qui vous permet de vous projeter sur la suite, et de comparer les devis à quelque chose.
Ce qu'un audit technique a changé chez ceux qui l'ont fait
Mesurez un audit à la décision qu'il a permise, pas à l'épaisseur du rapport. Sur les 3 situations du début de cet article, les 3 décisions étaient différentes :
- La PME du transport a arrêté ses licences et fait construire l'outil qui couvrait 90 % du besoin. Les coûts de fonctionnement ont baissé.
- DI&Care a mis un holà aux briques propriétaires de son agence, sans avoir la main sur le code. Quand l'agence a fermé 2 ans plus tard, la dépendance avait déjà été réduite.
- L'outil construit avec l'IA a reçu un ordre de traitement pour ses 3 sujets non abordés, avant d'accueillir des données réelles.
Dans les 3 cas, la décision portait sur des dizaines de milliers d'euros, et l'audit en a coûté quelques milliers. Cet écart n'est pas une promesse : c'est ce qui se passe quand on regarde avant de décider, au lieu de décider puis de découvrir.
Si votre décision est de reprendre le projet à quelqu'un d'autre, lisez le décryptage sur la reprise de projet informatique. Il détaille les 48 premières heures, la propriété du code et les 4 issues possibles. Et si l'application tourne encore mais qu'une seule personne chez vous sait comment, lisez le décryptage sur la dépendance à un seul développeur avant qu'elle ne parte.
Comment décider : la séquence, dans l'ordre
Voici les 7 étapes à suivre, dans cet ordre, sans en sauter une :
- 1
Écrire ce que vous attendez de l'audit en 1 phrase : reprendre, décider de refaire, préparer un changement de prestataire, ou simplement savoir où vous en êtes. La question change ce qu'on regarde en premier.
- 2
Rassembler les accès avant le premier jour : serveurs, fournisseurs, secrets, historique du code, backlog. Chaque accès qui manque est un jour perdu, ou une zone d'ombre dans le rapport.
- 3
Prévenir votre prestataire actuel, par écrit. Un audit n'est pas une accusation, et sa réaction fait partie du diagnostic.
- 4
Demander un livrable structuré : des risques avec criticité et domaine, des recommandations avec action, bénéfice, charge et complexité, un plan et une enveloppe. Refuser un rendu qui se termine par un devis de refonte.
- 5
Demander plusieurs options pour la suite : avec l'auditeur, avec des freelances, avec un prestataire externe, en interne. Si le rapport n'en propose qu'une, il a été écrit pour la vendre.
- 6
Décider sur la base des conséquences, pas de la longueur de la liste. 20 risques faibles pèsent moins qu'1 risque critique sur vos données.
- 7
Faire implémenter le plan par qui vous voulez. Si l'auditeur propose de le faire lui-même, c'est bon signe : il accepte d'être jugé sur le résultat de son propre plan.
Suivre ces 7 étapes ne demande pas de comprendre le code. Il suffit de demander la structure du livrable, et de refuser un rapport qui ne vous laisse qu'une porte de sortie. Et si l'audit révèle que personne ne tient la direction technique chez vous, la suite logique est un CTO externalisé, à temps partiel, le temps de remettre le projet sur ses rails. Et si vous avez tout construit vous-même, lisez d'abord ce que tranche une direction technique quand le dirigeant sait automatiser seul.
Auteur de l'article
Fabien Bousquet, CTO externalisé.
Pas une équipe, pas un sous-traitant. C'est moi qui vous écris, qui cadre, qui build, qui livre.
En savoir plus sur mon parcours →Questions fréquentes
Combien de temps dure un audit technique d'application ?
Comptez 2 semaines entre le premier accès et le livrable, pour quelques jours de travail effectif selon la taille de l'application. Le rendu fait 20 à 50 pages. Un audit qui promet 3 mois cherche à facturer 3 mois, et un audit qui promet 1 après-midi ne lit pas le code.
Un audit de code et un audit de sécurité, est-ce la même chose ?
Non, et la différence compte au moment de choisir. L'audit technique regarde la structure, la production, la gestion produit et l'IA, avec la sécurité au niveau des évidences : accès, secrets, cloisonnement. L'audit de sécurité va en profondeur, avec des tests d'intrusion, et c'est le métier de sociétés spécialisées. Le premier vous dit s'il faut le second.
Faut-il donner les accès à la production ?
Oui, en lecture seule : on peut regarder, pas modifier. Sans accès à la production, l'audit ne voit ni les performances réelles, ni les journaux, ni les alertes, ni les coûts. Il jugerait le plan de la maison sans entrer dedans, alors qu'un accès en lecture, limité dans le temps, suffit.
Que faire si mon prestataire refuse l'accès au code ?
Ce refus est déjà un résultat de l'audit. Vérifiez d'abord votre contrat : le code que vous avez payé vous appartient rarement par défaut. Si le code reste chez le prestataire, l'audit se fait sur ce qui est accessible, la production, les fournisseurs, les factures, et il documente la dépendance. C'est ce qui a permis, chez DI&Care, de dire stop aux briques propriétaires sans avoir la main sur le code.
L'audit sert-il si l'application a été construite avec l'IA ?
Plus qu'avant, parce que le code généré est homogène et souvent propre en apparence. Les problèmes sont ailleurs : une IA qui répond avec confiance quand elle ne sait pas, des environnements non cloisonnés, une dette fonctionnelle que personne n'a vue parce que tout le monde regardait l'écran. Un décryptage détaille ces 3 risques pour les outils internes construits avec l'IA.
L'audit débouche-t-il forcément sur une refonte ?
Non, et c'est le point à surveiller. Sur les 3 situations de cet article, 1 a conduit à refaire, 1 à réduire, et 1 à corriger dans l'ordre. Un audit qui conclut toujours à la refonte est un devis déguisé. Demandez plusieurs options chiffrées pour la suite.
Sources
Références consultées pour cette version du 24 août 2026. Les cas cités sont réels. DI&Care fait l'objet d'une étude de cas publique, les autres sont anonymisés.
Retrouvez tous les Décryptages.