L'essentiel

Reprendre un projet applicatif sans audit prealable, c'est s'engager a l'aveugle. Chez Nehos, nous refusons systematiquement de signer un contrat de TMA ou de reprise sans avoir realise un audit structuree en 5 etapes.

Les 5 etapes : 1) collecte des acces et de la documentation existante, 2) audit securite et scan CVE, 3) analyse qualite code avec SonarQube et PHPStan, 4) chiffrage de la dette technique, 5) roadmap de stabilisation et devis chiffre.

Cette methode protege le client autant que le prestataire : elle revele l'etat reel de l'application et permet de dimensionner correctement le contrat. Un audit de reprise dure 3 a 5 jours et coute entre 2 000 et 5 000 euros HT.

Audit de reprise de projet : nos 5 etapes avant de signer

La methode Nehos pour evaluer, chiffrer et securiser une reprise de projet applicatif. Avec check-list 30 points et cas client anonymise.

Adapté à toute taille de structure

Artisan

Startup

PME / TPE

ETI

Grand Groupe

Chokri Siala

·4 juin 2026·tma

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 risquees en ingenierie logicielle. Sans methode d'audit structuree, le prestataire decouvre les problemes apres la signature, quand il est trop tard pour ajuster le perimetre ou le budget. Chez Nehos, nous avons formalise une methode en 5 etapes que nous appliquons systematiquement avant chaque reprise. En 7 ans et plus de 80 reprises de projets, cette methode nous a permis d'eviter les mauvaises surprises et de chiffrer precisement l'effort necessaire. Voici comment elle fonctionne, etape par etape, avec un cas client anonymise pour illustrer les enjeux concrets.

#Etape 1 : collecte des acces et de la documentation existante

La premiere etape est aussi la plus revelatrice. Nous demandons au client de nous fournir la liste complete des acces necessaires pour auditer l'application : repository Git (avec l'historique complet des commits), acces aux environnements de staging et de production, documentation technique existante (schemas d'architecture, modele de donnees, specifications fonctionnelles), acces aux outils de suivi de bugs (Jira, GitLab Issues, Redmine), acces au serveur de logs et aux outils de monitoring. La rapidite et la completude de cette collecte sont un premier indicateur de la maturite du projet. Un client qui fournit un repository Git avec un historique propre, un README a 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 experience, 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 a 3 jours.

#Etape 2 : audit securite et scan CVE des dependances

Avant meme de lire une ligne de code metier, nous scannons l'ensemble des dependances 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 complementaires : Symfony Security Checker pour les vulnerabilites des bundles Symfony, npm audit ou yarn audit pour les dependances JavaScript et un scan OWASP Dependency-Check pour une couverture exhaustive. Le resultat est un rapport qui liste chaque vulnerabilite par niveau de severite (critique, haute, moyenne, basse) avec la version corrective disponible. Sur les 80 reprises realisees 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, restee en production pendant 4 ans sans mise a jour. L'audit securite nous permet de chiffrer immediatement le cout de mise en conformite et d'evaluer 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.

#Etape 3 : analyse qualite code avec SonarQube et PHPStan

Une fois la securite evaluee, nous analysons la qualite intrinsecque du code source. Notre stack d'analyse comprend SonarQube pour la mesure globale de la qualite (dette technique en jours-homme, couverture de tests, duplication de code, complexite cyclomatique), PHPStan au niveau 6 minimum pour l'analyse statique PHP (erreurs de typage, appels a des methodes inexistantes, variables non definies) et ESLint/TypeScript strict pour le code frontend. Les metriques cles 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 complexite cyclomatique moyenne par methode (seuil acceptable : moins de 10) et le nombre de code smells par millier de lignes. Ces metriques nous donnent un score de maintenabilite objectif qui determine directement le cout de la TMA. Une application avec 80% de couverture de tests et un code propre necessite moitie moins de temps d'intervention qu'une application avec 5% de couverture et du code spaghetti. C'est cette difference que nous chiffrons dans l'etape suivante.

#Etape 4 : chiffrage de la dette technique en jours-homme

C'est l'etape ou l'audit se transforme en chiffres exploitables pour la decision. Nous consolidons les resultats des etapes 2 et 3 dans un tableau de dette technique qui attribue un cout en jours-homme a chaque categorie de probleme identifie. Le chiffrage couvre quatre axes : la dette securite (mise a jour des dependances, correction des vulnerabilites, mise en conformite RGPD), la dette d'obsolescence (montee de version du framework, migration PHP, mise a jour des API tierces depreciees), la dette de testabilite (ecriture des tests manquants, mise en place du pipeline CI/CD) et la dette de documentation (redaction des specifications techniques, schemas d'architecture, procedures de deploiement). Le resultat est un tableau synthetique 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'etat de l'art en 6 mois). Ce chiffrage permet au client de prendre une decision eclairee : reprendre l'application en l'etat avec une TMA plus couteuse, investir dans un plan de remediation avant la TMA, ou dans les cas extremes, envisager une refonte partielle quand le cout de remediation depasse 50% du cout de reconstruction.

#Etape 5 : roadmap de stabilisation et devis chiffre

La derniere etape 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'etape 4 selon leur impact sur la stabilite et la securite de l'application. La roadmap type comprend le mois 1 consacre a la remediation securite (patchs CVE critiques, mise a jour des dependances 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 reduction de la dette d'obsolescence (montee de version framework, refactoring des modules les plus endettes). Chaque chantier est chiffre en jours-homme avec un livrable precis. Le devis inclut le cout de l'audit (generalement 3 a 5 jours), le cout de la phase de stabilisation et le cout de la TMA recurrente une fois l'application stabilisee. 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 acces au repository (le code etait sur le compte GitLab personnel du developpeur principal), un seul environnement de production sans staging et zero test automatise. Notre audit de reprise a revele 62 vulnerabilites dont 12 critiques, une couverture de tests de 0%, une dette technique chiffree a 45 jours-homme et une architecture monolithique sans separation des responsabilites. Nous avons propose un plan en trois phases : remediation securite en urgence sur 5 jours, stabilisation et mise en place du CI/CD sur 15 jours, puis TMA recurrente a 4 jours par mois. Le cout total de la phase de reprise etait de 18 000 euros HT, amortis en 6 mois par la reduction des incidents de production qui coutaient au client environ 3 500 euros par mois en perte de productivite.

#Check-list 30 points pour un audit de reprise complet

Voici les 30 points que nous verifions systematiquement lors d'un audit de reprise. Cette check-list est accessible a tout responsable technique qui souhaite structurer sa propre demarche d'evaluation avant de confier une reprise a un prestataire. Elle couvre les acces (repository Git avec historique, environnements dev/staging/prod, CI/CD pipeline, monitoring et logs, base de donnees, DNS et certificats SSL), la securite (scan CVE Composer et npm, headers de securite HTTP, configuration CORS, gestion des secrets et variables d'environnement, conformite RGPD des traitements de donnees), la qualite du code (analyse SonarQube globale, PHPStan niveau 6, couverture de tests, duplication de code, complexite cyclomatique, respect des standards PSR-12), l'architecture (separation des couches, gestion des dependances, patterns utilises, scalabilite horizontale, gestion du cache) et la documentation (README a jour, schemas d'architecture, modele de donnees documente, procedures de deploiement, guide de contribution pour les nouveaux developpeurs).

#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 cout d'un contrat TMA qui tourne mal parce que la dette technique a ete sous-estimee. Chez Nehos, nous considerons l'audit de reprise comme un investissement non negociable : il protege 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.

Sources

Questions & Réponses

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 complexite de l'application. Ce montant couvre 3 a 5 jours de travail d'un architecte senior : collecte des acces, scan de securite, analyse SonarQube, chiffrage de la dette technique et production d'une roadmap de stabilisation. L'audit est facture separement du contrat TMA et n'engage le client a aucune suite. Si le client decide de signer un contrat TMA avec Nehos, le cout de l'audit est generalement deduit des premiers mois de forfait.

Si le chiffrage de la dette technique depasse 50% du cout de reconstruction de l'application, nous le signalons clairement au client avec trois options. Option 1 : reprendre l'application en l'etat avec un contrat TMA plus couteux qui inclut un plan de remediation progressive. Option 2 : investir dans une phase de refactoring intensif de 2 a 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 donnees objectives pour prendre cette decision, pas de pousser une solution plutot qu'une autre.

Oui, c'est une condition non negociable chez Nehos. Nous refusons systematiquement de signer un contrat TMA sans avoir realise un audit prealable, meme si le client est presse. La raison est simple : sans audit, nous ne pouvons pas dimensionner correctement le contrat (nombre de jours-homme, SLA realisables, budget previsionnel) et nous prenons le risque de decouvrir des problemes majeurs apres la signature, ce qui deteriore la relation client. En 7 ans, cette politique nous a epargne de nombreux contentieux et nous a permis de maintenir un taux de renouvellement de contrat TMA superieur 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 perimetre (Java Spring, .NET, Ruby on Rails), nous pouvons realiser un audit partiel couvrant la securite, l'architecture et la documentation, mais pas l'analyse fine de la qualite du code metier. Dans ce cas, nous orientons le client vers un partenaire specialise dans la technologie concernee et nous nous concentrons sur les aspects transverses de l'audit (infrastructure, CI/CD, monitoring, documentation). Nous preferons etre honnetes sur nos limites plutot que de fournir un audit superficiel qui donnerait un faux sentiment de securite.

Exploration associée

reprise de projet abandonne service TMA Nehos reprendre un projet abandonne diagnostic de dette technique modernisation applicative 10 questions avant de signer un contrat TMA dette technique