Audit
Savoir ce que vaut votre application avant d'engager quoi que ce soit
Nous installons votre projet, nous le faisons tourner, nous en parcourons tous les rôles et nous en testons les limites. Vous en ressortez avec un document argumenté et un plan de remédiation chiffré — pas avec un avis.
Le protocole
Comment nous procédons
- 01
On installe votre projet chez nous
Pas de lecture de code à distance : le projet est installé sur notre machine et lancé, sur une base vierge ou sur un extrait de vos données. Cette étape seule est déjà un révélateur — un projet qui ne se lance pas en suivant son propre README raconte quelque chose.
- 02
On parcourt tous les rôles utilisateurs
Administrateur, client, partenaire, vendeur : chaque parcours est déroulé pour comprendre le métier avant de juger le code. On n'audite pas une application dont on n'a pas compris l'usage.
- 03
On teste les limites, pas seulement le chemin heureux
Est-ce qu'un utilisateur peut voir les données d'un autre ? Créer un objet rattaché à quelqu'un d'autre ? Les failles de droits ne se voient pas dans le code, elles se démontrent en les exploitant.
- 04
On passe l’outillage d’analyse
Analyse statique, vérification des dépendances vulnérables, scan de sécurité, couverture de tests. Les outils objectivent ce que la lecture seule laisserait au ressenti.
Le périmètre
Six domaines, une vingtaine de chapitres
La grille est la même d'un projet à l'autre : c'est ce qui permet de comparer, et de ne rien oublier.
Socle technique
- Versions du langage, du framework et fin de support
- Dépendances et failles de sécurité connues
- Base de données, schéma et index
- Hébergement et configuration serveur
Industrialisation
- Processus de déploiement et environnements
- Intégration et livraison continues
- Tâches planifiées et traitements asynchrones
- Supervision des erreurs et traçabilité
Qualité du code
- Conventions, homogénéité, langue du code
- Architecture et découpage métier
- Modèles, contrôleurs, vues, formulaires
- JavaScript et feuilles de style
Robustesse
- Présence et état des tests automatisés
- Couverture, et surtout ce qui n’est pas couvert
- Performance et requêtes en cascade
- Dimensionnement des files et des pools de connexion
Sécurité
- Droits d’accès entre utilisateurs, vérifiés par l’exploitation
- Protection CSRF, CORS, limitation de débit
- Secrets et identifiants en dur dans le code
- Données personnelles exposées dans les journaux
Exploitation
- Envoi d’e-mails et configuration par environnement
- Internationalisation et traductions
- Services tiers et dépendances externes
- Référencement, lorsque le projet est public
La notation
Chaque constat est qualifié
Un audit qui ne distingue pas le grave du discutable est inexploitable. Nous utilisons quatre niveaux.
Bon point
Ce qui fonctionne et qu’il faut conserver.
Point neutre
Un choix discutable, mais qui ne justifie pas d’intervenir.
Point négatif
Un écart aux bonnes pratiques, avec son impact expliqué.
Point bloquant
Ce qui empêche d’avancer, ou ce que nous n’avons pas pu auditer faute d’accès.
Un bon audit distribue les trois premiers niveaux. Un rapport qui ne contient que des points négatifs en dit plus long sur son auteur que sur le code qu'il examine.
Le livrable
Ce que vous recevez
Un document structuré, chapitre par chapitre
Une vingtaine de sections thématiques, chacune close par une recommandation explicite. Pas une liste de reproches : pour chaque constat, ce que ça implique et ce qu’on en fait.
Un plan de remédiation chiffré en jours-homme
Chaque chantier est estimé en fourchette — montée de versions, sécurisation des droits, mise en place des tests, CI/CD. Vous arbitrez sur des ordres de grandeur, pas sur des impressions.
Les questions à poser à votre prestataire
Un audit révèle presque toujours des zones d’ombre : historique de code non fourni, accès manquants, choix non documentés. Nous listons ce qu’il faut leur demander.
Une restitution orale avec vos équipes
Le document se lit, mais les arbitrages se discutent. Nous prenons le temps de reprendre les points critiques avec vos développeurs ou votre prestataire.
Les estimations sont exprimées en jours-homme, par fourchette. Nous préférons annoncer « 8 à 10 jours » et l'assumer plutôt qu'un chiffre précis qui donnerait une fausse impression de certitude sur un code que nous découvrons.
Quand un audit se justifie
- Vous héritez d’une application développée par quelqu’un d’autre et vous devez décider : reprendre ou refaire.
- Des dysfonctionnements se répètent sans que personne ne sache les expliquer.
- Vous envisagez de racheter une société, ou de vendre votre logiciel, et l’acquéreur demande un état des lieux.
- Votre prestataire actuel vous annonce un chiffrage que vous n’êtes pas en mesure d’évaluer.
- Vous changez d’équipe technique et vous voulez savoir dans quoi elle met les pieds.
Questions fréquentes
De quoi avez-vous besoin pour commencer ?
L’accès au dépôt de code — pas une simple archive, l’historique compte — un extrait de base de données exploitable, et si possible un accès serveur. Chaque élément manquant réduit la portée de l’audit, et nous l’indiquons explicitement dans le rapport plutôt que de combler par des suppositions.
Combien de temps cela prend-il ?
Comptez quelques jours selon la taille du projet. L’installation et la prise en main du métier représentent une part importante du travail : on ne juge pas utilement un code dont on n’a pas compris l’usage.
Est-ce que vous corrigez ce que vous trouvez ?
L’audit est un livrable autonome : vous pouvez le confier à votre équipe ou à un autre prestataire. Cela dit, il arrive qu’un point critique soit corrigé pendant l’audit lui-même, quand le risque ne permet pas d’attendre le rapport.
Auditez-vous aussi bien Magento que Ruby on Rails ?
Oui, ce sont nos deux terrains. La grille est la même — socle, industrialisation, qualité, robustesse, sécurité, exploitation — seuls les outils d’analyse et les points de contrôle diffèrent selon la technologie.
Le rapport est-il utilisable comme certification ?
Non, et nous le disons dans le rapport quand la question se pose. Un audit technique n’est pas une certification logicielle délivrée par un organisme accrédité. C’est un état des lieux argumenté, pas un label.
Vous héritez d'un projet et vous ne savez pas ce qu'il vaut ?
Dites-nous ce que vous avez entre les mains et ce que vous devez décider. Nous vous dirons ce qu'un audit peut vous apprendre — et ce qu'il ne pourra pas.
Demander un audit