Audit de reprise de projet : nos 5 étapes avant de signer
La méthode Nehos pour évaluer, chiffrer et sécuriser une reprise de projet applicatif. Avec check-list 30 points et cas client anonymise.
Nos clients types
Reprendre un projet developpe par un autre prestataire ou par une equipe interne qui a quitte l'entreprise est l'une des missions les plus risquées en ingénierie logicielle. Sans méthode d'audit structurée, le prestataire découvre les problèmes après la signature, quand il est trop tard pour ajuster le périmètre ou le budget. Chez Nehos, nous avons formalise une méthode en 5 étapes que nous appliquons systématiquement avant chaque reprise. En 7 ans et plus de 80 reprises de projets, cette méthode nous a permis d'éviter les mauvaises surprises et de chiffrer précisément l'effort nécessaire. Voici comment elle fonctionne, étape par étape, avec un cas client anonymise pour illustrer les enjeux concrets.
#Étape 1 : collecte des accès et de la documentation existante
La premiere étape est aussi la plus révélatrice. Nous demandons au client de nous fournir la liste complete des accès nécessaires pour auditer l'application : repository Git (avec l'historique complet des commits), accès aux environnements de staging et de production, documentation technique existante (schemas d'architecture, modèle de données, specifications fonctionnelles), accès aux outils de suivi de bugs (Jira, GitLab Issues, Redmine), accès au serveur de logs et aux outils de monitoring. La rapidité et la completude de cette collecte sont un premier indicateur de la maturité du projet. Un client qui fournit un repository Git avec un historique propre, un README à jour et des schemas d'architecture est un bon signe. Un client qui met 3 semaines a retrouver les identifiants du serveur de production est un signal d'alerte majeur. Dans notre expérience, 60% des projets repris n'ont aucune documentation technique exploitable. Ce constat conditionne l'effort de la phase d'audit : sans documentation, nous devons reconstituer l'architecture a partir du code source, ce qui augmente le temps d'audit de 2 à 3 jours.
#Étape 2 : audit sécurité et scan CVE des dépendances
Avant meme de lire une ligne de code métier, nous scannons l'ensemble des dépendances du projet pour identifier les vulnerabilites connues (CVE). Sur une application Symfony, cela couvre les packages Composer (PHP) et les packages npm/yarn (frontend). Nous utilisons trois outils complémentaires : Symfony Security Checker pour les vulnerabilites des bundles Symfony, npm audit ou yarn audit pour les dépendances JavaScript et un scan OWASP Dependency-Check pour une couverture exhaustive. Le résultat est un rapport qui liste chaque vulnérabilité par niveau de sévérité (critique, haute, moyenne, basse) avec la version corrective disponible. Sur les 80 reprises réalisées chez Nehos, la moyenne est de 47 vulnerabilites connues par projet, dont 8 critiques. Le record absolu : une application Laravel 5.4 avec 182 vulnerabilites dont 34 critiques, restée en production pendant 4 ans sans mise à jour. L'audit sécurité nous permet de chiffrer immédiatement le coût de mise en conformité et d'évaluer le risque pour le client. Si le nombre de CVE critiques depasse un seuil raisonnable, nous recommandons un plan de remediation prioritaire avant la prise en charge TMA.
#Étape 3 : analyse qualité code avec SonarQube et PHPStan
Une fois la sécurité évaluée, nous analysons la qualité intrinsecque du code source. Notre stack d'analyse comprend SonarQube pour la mesure globale de la qualité (dette technique en jours-homme, couverture de tests, duplication de code, complexité cyclomatique), PHPStan au niveau 6 minimum pour l'analyse statique PHP (erreurs de typage, appels a des méthodes inexistantes, variables non définies) et ESLint/TypeScript strict pour le code frontend. Les métriques clés que nous relevons sont la couverture de tests unitaires (seuil acceptable : 40% minimum, ideal : 70%), le ratio de duplication de code (seuil acceptable : moins de 5%), la complexité cyclomatique moyenne par méthode (seuil acceptable : moins de 10) et le nombre de code smells par millier de lignes. Ces métriques nous donnent un score de maintenabilite objectif qui determine directement le coût de la TMA. Une application avec 80% de couverture de tests et un code propre necessite moitié moins de temps d'intervention qu'une application avec 5% de couverture et du code spaghetti. C'est cette différence que nous chiffrons dans l'étape suivante.
#Étape 4 : chiffrage de la dette technique en jours-homme
C'est l'étape ou l'audit se transforme en chiffres exploitables pour la décision. Nous consolidons les résultats des étapes 2 et 3 dans un tableau de dette technique qui attribue un coût en jours-homme à chaque catégorie de problème identifie. Le chiffrage couvre quatre axes : la dette sécurité (mise à jour des dépendances, correction des vulnerabilites, mise en conformité RGPD), la dette d'obsolescence (montée de version du framework, migration PHP, mise à jour des API tierces dépréciées), la dette de testabilite (écriture des tests manquants, mise en place du pipeline CI/CD) et la dette de documentation (redaction des specifications techniques, schemas d'architecture, procedures de déploiement). Le résultat est un tableau synthétique qui presente la dette totale en jours-homme et en euros, avec trois scenarios : le scenario minimal (corriger uniquement les vulnerabilites critiques et les bugs bloquants), le scenario recommande (atteindre un niveau de maintenabilite acceptable en 3 mois) et le scenario optimal (remettre l'application a l'état de l'art en 6 mois). Ce chiffrage permet au client de prendre une décision éclairée : reprendre l'application en l'état avec une TMA plus coûteuse, investir dans un plan de remediation avant la TMA, ou dans les cas extremes, envisager une refonte partielle quand le coût de remediation depasse 50% du coût de reconstruction.
#Étape 5 : roadmap de stabilisation et devis chiffre
La dernière étape transforme l'audit en plan d'action concret. Nous construisons une roadmap de stabilisation sur 3 a 6 mois qui priorise les chantiers identifies dans l'étape 4 selon leur impact sur la stabilité et la sécurité de l'application. La roadmap type comprend le mois 1 consacre a la remediation sécurité (patchs CVE critiques, mise à jour des dépendances majeures), le mois 2 dedie a la stabilisation (correction des bugs les plus impactants, mise en place du monitoring), le mois 3 oriente vers l'amelioration de la testabilite (pipeline CI/CD, tests de non-regression sur les flux critiques) et les mois 4 a 6 centres sur la réduction de la dette d'obsolescence (montée de version framework, refactoring des modules les plus endettes). Chaque chantier est chiffre en jours-homme avec un livrable précis. Le devis inclut le coût de l'audit (généralement 3 a 5 jours), le coût de la phase de stabilisation et le coût de la TMA récurrente une fois l'application stabilisée. Cette transparence est notre marque de fabrique : le client sait exactement ce qu'il va payer, pourquoi, et ce qu'il obtiendra en retour.
#Cas client anonymise : reprise d'un ERP Symfony 4.4
Une ETI toulousaine dans le secteur logistique nous a contactes pour reprendre un ERP interne developpe en Symfony 4.4 par une agence qui avait ferme ses portes. Situation a la prise de contact : aucune documentation, aucun accès au repository (le code était sur le compte GitLab personnel du développeur principal), un seul environnement de production sans staging et zero test automatise. Notre audit de reprise a révélé 62 vulnerabilites dont 12 critiques, une couverture de tests de 0%, une dette technique chiffrée a 45 jours-homme et une architecture monolithique sans separation des responsabilités. Nous avons propose un plan en trois phases : remediation sécurité en urgence sur 5 jours, stabilisation et mise en place du CI/CD sur 15 jours, puis TMA récurrente a 4 jours par mois. Le coût total de la phase de reprise était de 18 000 euros HT, amortis en 6 mois par la réduction des incidents de production qui coûtaient au client environ 3 500 euros par mois en perte de productivité.
#Check-list 30 points pour un audit de reprise complet
Voici les 30 points que nous vérifions systématiquement lors d'un audit de reprise. Cette check-list est accessible a tout responsable technique qui souhaite structurer sa propre demarche d'évaluation avant de confier une reprise a un prestataire. Elle couvre les accès (repository Git avec historique, environnements dev/staging/prod, CI/CD pipeline, monitoring et logs, base de données, DNS et certificats SSL), la sécurité (scan CVE Composer et npm, headers de sécurité HTTP, configuration CORS, gestion des secrets et variables d'environnement, conformité RGPD des traitements de données), la qualité du code (analyse SonarQube globale, PHPStan niveau 6, couverture de tests, duplication de code, complexité cyclomatique, respect des standards PSR-12), l'architecture (separation des couches, gestion des dépendances, patterns utilises, scalabilite horizontale, gestion du cache) et la documentation (README à jour, schemas d'architecture, modèle de données documente, procedures de déploiement, guide de contribution pour les nouveaux développeurs).
#Conclusion : un audit de reprise, c'est une assurance
L'audit de reprise coute entre 2 000 et 5 000 euros HT selon la taille du projet. C'est une fraction du coût d'un contrat TMA qui tourne mal parce que la dette technique a été sous-estimée. Chez Nehos, nous considérons l'audit de reprise comme un investissement non négociable : il protège le client contre les mauvaises surprises et nous permet de dimensionner correctement notre engagement. Si vous envisagez de reprendre un projet applicatif, commencez par l'audit.
Questions frequentes : audit de reprise de projet
Un audit de reprise chez Nehos coute entre 2 000 et 5 000 euros HT selon la taille et la complexité de l'application. Ce montant couvre 3 a 5 jours de travail d'un architecte senior : collecte des accès, scan de sécurité, analyse SonarQube, chiffrage de la dette technique et production d'une roadmap de stabilisation. L'audit est facture séparément du contrat TMA et n'engage le client a aucune suite. Si le client decide de signer un contrat TMA avec Nehos, le coût de l'audit est généralement déduit des premiers mois de forfait.
Si le chiffrage de la dette technique depasse 50% du coût de reconstruction de l'application, nous le signalons clairement au client avec trois options. Option 1 : reprendre l'application en l'état avec un contrat TMA plus coûteux qui inclut un plan de remediation progressive. Option 2 : investir dans une phase de refactoring intensif de 2 à 3 mois avant de basculer en TMA standard. Option 3 : envisager une refonte partielle en strangler pattern, ou les modules les plus endettes sont reconstruits progressivement pendant que l'application existante continue de fonctionner. Notre role est de fournir au client les données objectives pour prendre cette décision, pas de pousser une solution plutôt qu'une autre.
Oui, c'est une condition non négociable chez Nehos. Nous refusons systématiquement de signer un contrat TMA sans avoir realise un audit préalable, même si le client est presse. La raison est simple : sans audit, nous ne pouvons pas dimensionner correctement le contrat (nombre de jours-homme, SLA réalisables, budget prévisionnel) et nous prenons le risque de découvrir des problèmes majeurs après la signature, ce qui détériore la relation client. En 7 ans, cette politique nous a épargne de nombreux contentieux et nous a permis de maintenir un taux de renouvellement de contrat TMA supérieur a 90%.
Notre expertise couvre les stacks Symfony, Laravel, React, Next.js, Vue.js et les architectures API REST/GraphQL. Pour les technologies hors de notre périmètre (Java Spring, .NET, Ruby on Rails), nous pouvons réaliser un audit partiel couvrant la sécurité, l'architecture et la documentation, mais pas l'analyse fine de la qualité du code métier. Dans ce cas, nous orientons le client vers un partenaire specialise dans la technologie concernée et nous nous concentrons sur les aspects transverses de l'audit (infrastructure, CI/CD, monitoring, documentation). Nous préférons être honnêtes sur nos limites plutôt que de fournir un audit superficiel qui donnerait un faux sentiment de sécurité.