Audit d’une application existante

Audit d’une application existante

Un audit n’est ni une revue rapide du code ni une liste de remarques de style. Il remplace les hypothèses par des informations vérifiées : ce que fait le système, les processus métier qui en dépendent, les risques et les premières actions utiles. Même avec une documentation incomplète, une application ancienne peut contenir un savoir précieux sur les exceptions, les prix, les documents, les clients et les intégrations.

Les questions métier définissent le périmètre

On part des conséquences, pas de la version du framework. Les commandes, paiements, factures et accès clients sont-ils prévisibles ? Qu’est-ce qui bloque l’évolution ? Quelles données doivent rester cohérentes ? Qui traite un incident et comment l’entreprise en est-elle informée ?

Processus métier
commandes • paiements • documents • accès
                    │
                    ▼
Domaines audités
code et dépendances • données • intégrations • sécurité
tests • déploiement • workers • supervision

L’examen peut couvrir versions de PHP et du framework, bibliothèques, architecture, requêtes et migrations de base, API, authentification, autorisation, frontières entre organisations, secrets et déploiement. Il ne constitue pas automatiquement un audit de sécurité complet ni la preuve qu’aucune vulnérabilité n’existe : sa portée dépend du périmètre convenu et des éléments accessibles.

Du constat à la décision

Le rapport distingue fait et interprétation. Un log montrant l’arrêt d’un worker de facturation est une preuve. Le risque de documents en attente pour des commandes payées découle de cette preuve et du processus décrit. La priorité dépend aussi de l’impact métier, de la fréquence et des moyens de reprise.

| Élément | Exemple | |---|---| | Observation | Le worker de facturation ne redémarre pas après certains déploiements. | | Preuve | Logs, configuration et historique des livraisons. | | Risque | Des commandes payées peuvent attendre leur document. | | Recommandation | Vérifier les workers, rendre le statut visible, définir une reprise. | | Priorité | Définie avec l’entreprise selon effet et urgence. |

Exemple : système Symfony de commandes fictif

Imaginons une application Symfony gérant checkout, paiements, factures, e-mails et espace opérationnel. Cet exemple ne décrit pas un projet client GiSoft. L’audit peut montrer un checkout stable, mais des callbacks de paiement mal vérifiés, des jobs de facture sans statut visible et des relances manuelles susceptibles de créer des doublons.

Cela n’impose pas le remplacement du système. Nous vérifions d’abord l’état de commande qui fait foi, la frontière entre logique applicative et prestataire de paiement, le comportement lors des délais dépassés, les tentatives conservées et les tests du workflow critique. Un identifiant stable aide à reconnaître le même dossier, mais l’idempotence exige aussi un état durable, la maîtrise de la concurrence, des contraintes d’unicité et un comportement compatible du prestataire.

Données, exploitation et sécurité

L’audit examine la responsabilité des données et le risque de créer deux systèmes de référence par synchronisation. Les performances sont évaluées à partir des requêtes et de la charge réelles, sans supposer que tout SQL ou monolithe doit être remplacé. Il couvre aussi relances, délais, webhooks, identifiants d’intégration, workers, sauvegardes, supervision et documentation de reprise.

Le contrôle d’accès est vérifié côté serveur : identité, rôles, autorisations, isolation des organisations et comptes désactivés. Masquer un bouton ne protège rien. Pour les informations confidentielles, nous convenons des limites d’accès, limitons l’exposition et signalons les zones qui n’ont pas pu être vérifiées.

Résultats possibles

Constats + contexte métier
            │
            ├── conserver un module stable
            ├── appliquer une protection immédiate
            ├── stabiliser l’exploitation
            ├── moderniser un domaine ciblé
            └── préparer un remplacement ou une réécriture plus large

Un rapport d’audit n’est ni une conception technique achevée ni une garantie de résultat. Il documente le périmètre, les constats vérifiés, les hypothèses et limites, les risques et effets métier, les recommandations et un ordre de travail justifié. Il indique aussi les décisions qui exigent davantage d’éléments ou une étude distincte.

GiSoft associe échanges avec les personnes qui utilisent le système, analyse technique et comportement en production. L’entreprise obtient ainsi une base pour choisir protection, stabilisation, modernisation progressive, remplacement de module ou reconstruction plus large, au lieu de décider sur le seul âge de la technologie.