Audit d’application métier et audit de code : savoir ce que vaut vraiment votre logiciel
Votre application fait tourner une partie de votre activité. Mais depuis quelque temps, les questions s’accumulent. Chaque évolution coûte plus cher que prévu. Les bugs reviennent. Le prestataire d’origine est parti, ou l’application a été construite en quelques semaines avec un outil d’intelligence artificielle. Et quelqu’un vient de prononcer la phrase redoutée : « il faudrait tout refaire ».
Avant de décider, il faut savoir. L’audit d’application examine en profondeur votre logiciel, du code à la base de données en passant par l’architecture, la sécurité et l’hébergement, pour répondre à une question simple : que faut-il en faire ? Chez Doing, cet audit est mené par des développeurs qui conçoivent et maintiennent des applications métier depuis plus de trente ans. Ils regardent votre code comme s’ils devaient le reprendre demain. Cet audit fait partie de nos audits informatiques.
Dans quelles situations auditer une application métier ?
Une application ancienne devenue difficile à faire évoluer
Technologie vieillissante, documentation absente, développeurs d’origine partis : c’est le cas typique d’une application legacy. L’audit évalue ce qui peut être conservé et prépare une éventuelle reprise d’application legacy, sans sacrifier les règles métier accumulées au fil des années.
Une application construite avec l’intelligence artificielle
Les outils de génération de code permettent de passer d’une idée à une application fonctionnelle en un temps record. Le passage en production pose d’autres questions : sécurité, tenue en charge, tests, cohérence de l’architecture. L’audit identifie ce qui tient et ce qui doit être consolidé avant d’ouvrir l’application à de vrais utilisateurs. La suite est détaillée dans notre page consacrée à la reprise d’une application développée avec l’IA.
Un changement de prestataire
Vous reprenez la main sur une application développée par un autre prestataire, ou vous envisagez d’en changer. L’audit établit un état des lieux neutre de ce dont vous héritez, et sécurise la transition : accès au code, aux environnements, aux données.
Un rachat, une levée de fonds ou une cession
Lorsque l’application est un actif stratégique, les acquéreurs et les investisseurs veulent en connaître la solidité. L’audit technique, souvent appelé due diligence technique, documente la qualité du produit, ses risques et les investissements à prévoir.
Des problèmes récurrents
Lenteurs, plantages, bugs qui reviennent après chaque correction, utilisateurs qui perdent confiance. L’audit remonte à la cause plutôt que de traiter les symptômes un par un.
Avant une évolution majeure
Nouvelle fonctionnalité d’envergure, ouverture à des milliers d’utilisateurs, connexion à un nouvel ERP, version mobile. L’audit vérifie que les fondations supporteront la charge, et évite de construire un étage supplémentaire sur un socle fragile.
Ce que nous analysons
L’architecture. Comment l’application est-elle organisée ? Les responsabilités sont-elles clairement séparées ? L’ensemble peut-il évoluer sans que chaque modification ne se répercute partout ?
La qualité du code. Lisibilité, respect des conventions, duplication, complexité, présence de tests automatisés. Un code difficile à lire est un code coûteux à faire évoluer, quel que soit le talent de celui qui l’a écrit.
La base de données et les requêtes. Structure du schéma, index, requêtes lentes ou exécutées en cascade, cohérence des données. C’est souvent là que se cachent les problèmes de performance les plus spectaculaires, et les plus simples à corriger.
Les dépendances et les versions. Frameworks, bibliothèques et langages : sont-ils encore maintenus ? Quelles montées de version faudra-t-il absorber, et à quel coût ? Une application qui repose sur une version en fin de support devient une application qui ne reçoit plus de correctifs de sécurité.
La sécurité applicative. Authentification, gestion des droits, protection contre les failles les plus répandues répertoriées par l’OWASP, stockage des données sensibles, gestion des secrets. Nous revoyons le code et la configuration ; cette revue complète, sans le remplacer, un test d’intrusion lorsqu’il est exigé.
La performance. Temps de réponse, consommation de ressources, comportement sous charge. Nous observons l’application en fonctionnement, pas seulement son code.
L’hébergement et l’exploitation. Environnements, procédures de déploiement, sauvegardes, supervision. Une application bien écrite mais mal exploitée reste une application fragile.
La documentation et la connaissance. Qui sait comment fonctionne l’application ? Qu’est-ce qui est écrit, et qu’est-ce qui n’existe que dans la tête d’une personne ?
L’éco-conception. Poids des échanges, requêtes inutiles, ressources surdimensionnées : en nous appuyant sur le RGESN, nous identifions les gains possibles, qui se traduisent le plus souvent aussi par un gain de performance et de coût d’hébergement.
Les technologies que nous auditons
Nos équipes auditent des applications construites avec les technologies qu’elles pratiquent au quotidien : PHP, qu’il soit natif ou basé sur Symfony ou Laravel, Node.js, Vue.js, React, Angular, Flutter, Cordova ou Ionic, avec des bases MySQL, MariaDB, PostgreSQL ou MongoDB. Nous intervenons aussi régulièrement sur des applications plus anciennes ou reliées à des systèmes historiques, comme des webservices AS400.
Notre méthode d’audit d’application
L’audit correspond aux deux premiers temps de notre chemin d’accompagnement : Éclairer & Guider, pour comprendre la situation réelle, puis Révéler, pour faire émerger ce qui a de la valeur et ce qui doit changer.
- Lancement. Nous alignons les objectifs de l’audit et les questions auxquelles il doit répondre, puis nous vérifions les accès : dépôt de code, environnements, base de données, documentation.
- Analyse outillée. Des outils d’analyse automatique mesurent la qualité du code, repèrent les dépendances obsolètes et les vulnérabilités connues. Ils donnent des indicateurs objectifs, mais pas de jugement.
- Lecture experte. Nos développeurs et lead développeurs lisent le code, examinent l’architecture et observent l’application en fonctionnement. C’est cette lecture humaine qui permet de distinguer un défaut anecdotique d’un problème structurel.
- Entretiens. Avec les utilisateurs pour comprendre les usages et les irritants, et avec l’équipe ou le prestataire en place lorsque c’est possible, pour comprendre l’histoire des choix techniques.
- Point d’étape. Les premiers constats sont partagés à mi-parcours, pour ajuster le périmètre si nécessaire.
- Restitution. Présentation des conclusions aux décideurs et aux équipes techniques, remise du rapport et du plan d’action.
Le verdict : conserver, assainir, reprendre ou réécrire
Un audit n’a de valeur que s’il aide à décider. Chaque audit Doing se conclut par une recommandation argumentée, parmi quatre grandes options souvent combinées module par module.
| Recommandation | Quand elle s’impose | Ce qu’elle implique |
|---|---|---|
| Conserver | L’application est saine, les problèmes sont ponctuels | Corrections ciblées et maintenance organisée |
| Assainir | La base est bonne, mais la dette technique freine les évolutions | Refactoring progressif, mises à jour, ajout de tests |
| Reprendre | La technologie ou certaines parties sont à bout de souffle, mais les règles métier ont de la valeur | Migration progressive, zone par zone, sans interrompre l’activité |
| Réécrire | Le socle ne permet plus d’évoluer à un coût raisonnable | Nouvelle application, en s’appuyant sur l’existant comme spécification |
Dans la grande majorité des cas, la réponse n’est pas la réécriture complète. Une application en service contient des années de règles métier et de cas particuliers : les jeter par principe coûte cher et fait prendre des risques inutiles. Quand une modernisation s’impose, nous privilégions une approche progressive, que nous détaillons dans notre article sur la refonte complète ou la modernisation progressive.
Ce que contient le rapport d’audit
- Une synthèse pour la direction, lisible sans bagage technique, avec la recommandation principale et son ordre de grandeur budgétaire.
- Une évaluation par axe : architecture, code, données, sécurité, performance, exploitation, documentation.
- Des constats classés par criticité, du risque à traiter sans attendre à l’amélioration souhaitable.
- Un plan d’action priorisé et chiffré, distinguant les corrections rapides des chantiers de fond.
- Des annexes techniques directement exploitables par l’équipe qui mettra en œuvre les recommandations.
Quelques mois après la mise en œuvre, un audit de contrôle permet de vérifier que les recommandations ont été appliquées et que la trajectoire est la bonne.
Et après l’audit ?
Le rapport vous appartient et vous laisse libre de la suite : confier les corrections à votre équipe, à votre prestataire actuel ou à un autre. Si vous souhaitez que nous prenions le relais, nos équipes peuvent assurer l’assainissement, la reprise ou la réécriture, puis le maintien en conditions opérationnelles, par sprints de trois semaines avec des livraisons régulières que vous validez au fil de l’eau. L’audit aura alors servi de feuille de route, et aucune connaissance ne sera perdue entre le diagnostic et la réalisation.
Questions fréquentes sur l’audit d’application
Combien de temps dure un audit d’application ?
Entre une et quatre semaines selon la taille de l’application, le nombre de technologies en jeu et la profondeur d’analyse attendue. Un premier échange permet de fixer un périmètre et un calendrier précis.
Faut-il nous donner accès au code source ?
Oui, c’est indispensable pour un audit sérieux, ainsi qu’un accès aux environnements et, si possible, à la base de données. Ces accès sont encadrés par un engagement de confidentialité. Si vous ne disposez pas vous-même du code, l’audit commence par vérifier que vous pouvez le récupérer : c’est parfois le premier risque à lever.
Pouvez-vous auditer une application générée par l’IA ?
Oui, c’est une demande de plus en plus fréquente. Ces applications posent des questions spécifiques : cohérence d’architecture, sécurité, tests, capacité à tenir la charge. L’audit permet de savoir ce qui peut être conservé et ce qui doit être consolidé avant la mise en production.
Mon prestataire actuel doit-il être informé ?
C’est préférable, et souvent nécessaire pour obtenir les accès. L’audit est factuel et constructif : il ne vise pas à désigner un coupable, mais à éclairer une décision.
L’audit inclut-il un test d’intrusion ?
Non. Nous réalisons une revue de sécurité du code, des dépendances et de la configuration, qui identifie la plupart des vulnérabilités courantes. Si votre contexte réglementaire impose un test d’intrusion, il sera réalisé par un prestataire spécialisé, et notre audit l’aura préparé.
Parlons de votre application autour d’un café
Vous avez un doute sur la solidité de votre application, une décision de refonte à prendre, ou une application construite rapidement qui doit passer en production ? Commençons par en parler. Un premier échange sans engagement suffit souvent à identifier ce qui doit être vérifié en priorité.
Nous sommes au 15 rue Camille de Rochetaillée, à Saint-Étienne. Contactez-nous ou appelez-nous au 04 77 42 37 37.
