Audit code source : partir d’un dépôt exploitable
Un répertoire de fichiers ne prouve pas que l’application est reproductible. Demandez la version du code correspondant à la production, les instructions de construction et la liste des outils nécessaires. Une application peut dépendre d’un fichier local, d’une bibliothèque ancienne ou d’un réglage présent uniquement sur le poste du développeur. Ce sont ces dépendances qu’il faut rendre visibles.
- Version du dépôt correspondant à l’application utilisée.
- Procédure de construction sur un environnement séparé.
- Inventaire des bibliothèques, licences et configurations.
- Accès encadré aux documents qui décrivent les échanges.
Commencez par l’audit fonctionnel du logiciel existant pour choisir les parcours à examiner. L’analyse du code doit répondre aux besoins de modernisation applicative, plutôt que produire une liste d’avertissements sans conséquence métier.
Lire les règles qui engagent le métier
Un calcul de remise, un changement de statut ou un verrou de période mérite une lecture ciblée. L’auditeur suit les entrées, les validations et les sorties, puis compare le comportement aux explications des utilisateurs. Il identifie les règles dupliquées, les paramètres codés en dur et les corrections manuelles qui contournent le fonctionnement prévu.
| Examen | Constat à documenter | Décision possible |
|---|---|---|
| Règle de calcul | Emplacement, entrées et arrondis | Conserver avec un test de référence |
| Validation | Contrôle absent ou différent selon les écrans | Centraliser et tester le refus |
| Échange de fichiers | Chemin et format dépendants d’un poste | Documenter ou remplacer l’échange |
| Traitement planifié | Reprise après erreur non définie | Prévoir un mécanisme de reprise |
| Composant tiers | Version et conditions d’utilisation | Mettre à niveau ou isoler le composant |
Le guide sur l’automatisation Excel et les macros VBA décrit les fiches de règles. Pour une application connectée à une base métier, un audit SQL Server permet d’examiner séparément les traitements stockés et les symptômes de performance.
Encadrer les essais et l’accès aux données
La lecture du code peut être complétée par une construction, des tests et l’exécution de parcours sur un environnement séparé. Le rapport doit indiquer ce qui a été effectivement rejoué. Une analyse statique seule ne démontre pas que les exports sont justes ou que les opérations simultanées produisent le résultat attendu.
La CNIL recommande d’encadrer les développements informatiques, notamment de protéger les données dans les environnements de travail et de test. Choisissez avec l’équipe des jeux adaptés aux essais. Les fichiers de configuration et les journaux doivent être manipulés comme des éléments sensibles lorsqu’ils contiennent des accès ou des données personnelles.
- Définir le périmètre autorisé et les environnements examinés.
- Préparer des données de test représentatives et maîtrisées.
- Construire et exécuter les parcours prioritaires.
- Comparer les résultats attendus et enregistrer les écarts.
Les scénarios du plan de recette de l’application peuvent devenir des tests de non-régression. Cette démarche prépare une reprise technique ; une évaluation spécialisée de sécurité relève d’un périmètre à définir séparément.
Décider entre conservation et réécriture
Le rapport utile présente des options : documenter et sécuriser la construction, remplacer un composant, isoler une règle, ou réécrire un module. Pour chaque option, demandez les prérequis, les dépendances et les essais nécessaires. Une impossibilité de construire doit être distinguée d’une procédure simplement manquante : la seconde peut parfois être documentée par l’équipe actuelle.
Les fichiers remis et les droits de les exploiter sont à vérifier séparément. L’article L131-3 prévoit la désignation des droits cédés et de leur domaine pour les contrats auxquels il s’applique. La qualification et la chaîne de droits doivent être examinées selon le contrat. Faites préciser les usages, modifications et conditions de reprise, avec les livrables décrits dans le guide maintenance et réversibilité.
- Constats avec référence à une version, un module ou un parcours.
- Limites de l’examen et informations qui restent à obtenir.
- Actions classées selon le risque métier et les dépendances.
- Conditions de reprise par une autre équipe.
Questions pratiques
Quels livrables attendre de l’audit ?
Un inventaire, les preuves de construction ou leurs obstacles, des constats localisés et des options de reprise. Le rapport doit nommer les modules examinés et les tests exécutés. Les éléments non accessibles restent explicitement hors conclusion.
Faut-il tout réécrire si le code est ancien ?
L’âge seul ne décide pas de la trajectoire. Examinez la possibilité de construire, les dépendances, les droits et les usages à conserver. Une reprise par modules peut être comparée à une refonte, avec les mêmes critères de réception.
Sources
Sources officielles consultées le 1er octobre 2026.