Vous avez herite d'un code legacy que personne ne veut maintenir. Prestataire parti, documentation absente, mises en production bloquees depuis six mois: c'est exactement le type de projet qu Eurastech reprend chaque semaine a Casablanca, Rabat et Fès. Ce guide explique comment stabiliser un code legacy, identifier les risques critiques en 72 heures, et relancer les évolutions sans tout reecrire. Il s'adresse aux DSI, DG et responsables IT qui cherchent une méthode concrète plutôt qu'un refactoring théorique.
Qu'est-ce que le code legacy et pourquoi il bloque vos projets
Un code legacy, ou système herite, est un logiciel encore en production mais devenu difficile a maintenir. Soit parce que les technologies ont vieilli, soit parce que l équipe qui l a écrit n'est plus la, soit parce qu'il a accumule trop de dette technique. Le risque n'est pas esthetique, il est opérationnel. Chaque correctif prend trois fois plus de temps, chaque déploiement devient risque, chaque départ de développeur fait perdre un pan de connaissance.
Dans les PME marocaines, le schéma typique ressemble a ceci: une application Laravel 5 ou PrestaShop 1.6, plus supportee depuis la fin du support officiel, connectée a une base MySQL 5.6 et déployée sur un serveur OVH sans CI/CD. Les versions de PHP ou Node sont plusieurs cycles en retard, les dépendances ont des CVE ouvertes, et la personne qui connaissait le code travaille maintenant en Europe.
Définition rapide: la dette technique est le coût cache accumule par des raccourcis pris pendant le développement. Elle devient critique quand elle empeche les nouvelles fonctionnalités d avancer et quand le coût d'une évolution dépassé sa valeur business.
5 signes qu'un projet a besoin d'une reprise en urgence
Voici les signaux que nous voyons systématiquement avant une intervention de reprise, tires de nos derniers audits menes pour des PME et ETI marocaines.
- Le déploiement prend plus de 2 heures ou se fait manuellement par FTP. Aucun pipeline automatise, aucun rollback fiable.
- Aucun environnement de staging fonctionnel. Les bugs sont decouverts en production par les utilisateurs finaux.
- Une seule personne connaissait le code et elle n'est plus dans l'entreprise. L équipe actuelle touche au code avec crainte.
- Les mises à jour de sécurité sont bloquees car monter une version de framework casse l'application.
- Le temps entre demande métier et mise en production dépassé 6 semaines pour un changement mineur.
Si trois de ces cinq points s appliquent, la dette technique est déjà devenue un risque business. Si quatre ou cinq s appliquent, vous etes dans le cas d'une reprise prioritaire.
Code généré par IA: le nouveau legacy express
Depuis 2024, une nouvelle categorie de projets arrive en reprise: les applications générées principalement par IA (ChatGPT, Claude, Cursor, v0). Le paradoxe est qu elles deviennent legacy en quelques mois au lieu de plusieurs années. Les raisons sont toujours les mêmes.
- Pas de coherence architecturale entre les modules, chaque iteration IA ayant reinvente les conventions.
- Tests absents ou hallucines: certains tests passent mais ne testent rien de réel.
- Dépendances obsolètes installees au moment du prompt initial et jamais mises à jour.
- Code duplique a grande échelle parce que l IA n avait pas le contexte complet du projet.
Ce que ça veut dire concretement: un projet généré par IA qui tourne depuis 9 mois a souvent besoin des mêmes interventions qu'un Laravel 5 de 2017. La reprise suit exactement le même protocole: audit, identification des parties non maintenables, reecriture ciblée. La seule différence est la vitesse d accumulation de la dette.
La méthode Eurastech: audit 72h, stabilisation, handover
Notre protocole de reprise de projet legacy se deroule en quatre phases. Chacune a un livrable date et verifiable, pas une vague intention.
Phase 1 - Triage sous 24h
Premier contact technique dans les 24 heures ouvrees. Objectif: identifier ce qui peut tomber en production cette nuit. Nous demandons accès Git, accès serveur, accès monitoring (ou installation rapide si absent). Livrable: liste des risques critiques avec niveau de probabilite et impact.
Phase 2 - Audit code et infrastructure sous 72h
Nous cartographions la codebase, mesurons la couverture de tests, scannons les CVE ouvertes, evaluons la qualité des dépendances, et documentons l architecture réelle. Livrable: rapport avec trois listes priorisees: quick wins (moins d'une semaine), stabilisation (1 a 3 mois), refactoring cible (3 a 6 mois).
Phase 3 - Stabilisation
Nous executons les quick wins en premier pour redonner confiance a l équipe. Typiquement: mise en place d'un CI basique, monitoring Sentry, backup automatise de la base, correctifs de sécurité bloquants, environnement de staging. Cette phase dure entre 4 et 12 semaines selon la taille de la codebase.
Phase 4 - Handover ou maintenance continue
Deux sorties possibles. Soit nous rendons le projet a votre équipe interne avec documentation runbook et formation (2 a 3 sessions). Soit nous continuons en maintenance applicative sous un forfait Silver ou Gold avec SLA engage. Le choix se fait en fin de phase 3, jamais au départ.
Un projet bloque en production ? Demandez un audit 72h de votre codebase. Premier contact technique sous 24h ouvrees, a Casablanca, Rabat ou à distance.
Trois cas réels de reprise que nous voyons au Maroc
Les reprises ne se ressemblent pas, mais elles rentrent dans trois grandes familles.
Cas 1 - E-commerce PrestaShop pirate ou instable. Site qui généré du chiffre mais tombe a repetition, avec modules tiers obsolètes et back-office lent. Intervention typique: nettoyage des modules, mise à jour ciblée, CDN, monitoring et plan de migration vers PrestaShop 8 sur 6 mois.
Cas 2 - SaaS B2B Laravel sans lead technique. L associe technique est parti, l équipe restante ne fait que du métier. Intervention: documentation, mise en place CI/CD, suite de tests d intégration sur les parcours critiques, montee de version progressive Laravel 5 vers 11.
Cas 3 - MVP généré par IA en production. Projet lance rapidement, utilisateurs réels, mais chaque évolution casse trois autres choses. Intervention: audit architectural, reecriture des modules les plus fragiles, mise en place de garde-fous (types stricts, tests, linting), puis reintegration progressive de l IA pour la suite du développement.
Dans les trois cas, le budget et le délai varient, mais la méthode reste la même. C'est ce que nous detaillons sur la page crisis-takeover.
Combien coûte la reprise d'un projet legacy au Maroc
Le coût d'une reprise dépend de trois facteurs: taille de la codebase, criticite des risques identifiés, et niveau de reprise souhaite (stabilisation seule vs refactoring cible). Ordres de grandeur indicatifs pour une PME marocaine.
| Taille projet | Audit 72h | Stabilisation (10 sem) | Refactoring cible (6 mois) |
|---|---|---|---|
| Petit (moins de 30k lignes) | 15 a 25k MAD | 80 a 150k MAD | 200 a 400k MAD |
| Moyen (30 a 100k lignes) | 25 a 40k MAD | 150 a 300k MAD | 400 a 800k MAD |
| Grand (plus de 100k lignes) | 40 a 60k MAD | 300 a 500k MAD | 800k a 1,5M MAD |
Ces fourchettes incluent l équipe senior mixte (tech lead, développeurs, ops) nécessaire pour absorber le pic. Elles excluent les licences tierces (Sentry, monitoring, cloud) qui restent a la charge du client.
Regle de décision simple: si la stabilisation coûte moins de 6 mois de maintenance future, elle est rentable. Nous evitons systématiquement la reecriture complète sauf contrainte imposee, comme une sortie d'un framework non supportable, une non-conformité CNDP ou un arrêt éditeur definitif.
Comment choisir le bon partenaire pour reprendre votre codebase
Tous les prestataires ne savent pas reprendre un projet qu ils n'ont pas écrit. Les signaux a vérifier avant d engager.
- Capacité a travailler sans le prestataire précédent. Pas besoin de documentation complète pour démarrer l audit.
- Expérience multi-stack. Un partenaire mono-technologie ne pourra pas auditer un écosystème hétérogène (Laravel, Node, legacy PrestaShop, scripts Python).
- Processus d'audit formalise avec livrable date, pas une mission ouverte au temps passe.
- Transparence sur ce qu'il ne faut PAS reecrire. Un bon prestataire vous dira quand la stabilisation suffit.
- Couverture geographique adaptee: interventions sur site a Casablanca, Rabat, Fès, ou en remote avec disponibilité horaires Maroc.
Point conformité CNDP (loi 09-08): si votre code legacy traite des données personnelles de clients marocains (CRM, e-commerce, portails B2B), la reprise doit inclure un volet conformité. Pseudonymisation des logs, gestion des droits d'accès, durées de conservation. Beaucoup de projets herites ne sont pas conformes sans le savoir, et cette non-conformité est souvent ce qui bloque les nouveaux partenariats B2B.
Pour consulter notre page crisis-takeover complète et nos études de cas sectorielles, voir les liens correspondants.
FAQ
En combien de temps pouvez-vous intervenir sur un projet legacy en crise ?
Premier contact technique sous 24 heures ouvrees. Audit priorise livre en 72 heures. Pour un incident critique en production, une équipe senior se mobilise le jour même sur Casablanca, Rabat, Fès ou en remote. Aucun onboarding long avant de commencer a regarder le code.
Pouvez-vous reprendre du code généré par IA (ChatGPT, Cursor, Claude) ?
Oui. C'est devenu un quart de nos reprises en 2025-2026. Nous auditons la coherence architecturale, identifions les modules non maintenables, reecrivons cible, et remettons en place les garde-fous (tests réels, CI, monitoring). Expertise Next.js, Astro, Laravel, Node, Python.
Travaillez-vous sans accès a l ancien prestataire ?
Oui, c'est le cas par defaut. Nous reprenons depuis zero: accès Git, accès serveur, accès base de données, accès monitoring. Si un de ces accès manque, nous aidons a le récupérer auprès de l hebergeur ou des plateformes concernées. Objectif: vous rendre le contrôle complet en moins de 10 jours ouvres.
Refactorez-vous systématiquement ou essayez-vous de garder le code existant ?
Nous gardons le code existant chaque fois que c'est economiquement justifie. Reecrire est long, coûteux et risque, c'est notre dernier recours. Nous preferons stabiliser, sécuriser et documenter, puis refactorer uniquement les modules qui bloquent vraiment l évolution business.
Quelle différence entre reprise et maintenance applicative ?
La reprise est une intervention limitee dans le temps (3 a 6 mois) pour remettre un projet a un niveau maintenable. La maintenance applicative est un forfait récurrent (Silver ou Gold) qui prend le relais ensuite. Beaucoup de clients commencent par une reprise et basculent en maintenance après handover.
Intervenez-vous sur PrestaShop 1.6 et Laravel 5 encore en production ?
Oui. Une part significative des projets e-commerce marocains tourne encore sur ces versions non supportees. Nous pouvons soit sécuriser la version actuelle avec patches et monitoring renforce, soit piloter une migration vers PrestaShop 8 ou Laravel 11 selon votre budget et votre calendrier.
Comment etes-vous factures pendant une reprise ?
L audit 72h est au forfait fixe. La stabilisation est au temps passe ou par sprints de 2 semaines, avec point de décision a chaque sprint. Si vous basculez en maintenance, vous choisissez un forfait Silver ou Gold. Aucun engagement long automatique, chaque phase se décidé separement.
Ressources complémentaires
Pour aller plus loin selon votre cas: audit de code 72h pour PME si vous voulez la méthode détaillée du diagnostic, migration Laravel 11 pour un projet Laravel ancien, migration PrestaShop 8 pour un e-commerce a moderniser, et nearshore Maroc si vous etes une PME européenne qui évalué le Maroc pour sa reprise de projet.
prêt à reprendre le contrôle de votre codebase ? Eurastech intervient a Casablanca, Rabat, Fès et en remote sur toute l Afrique francophone. Audit 72h au forfait, équipe senior, engagement phase par phase. Demander un audit 72h ou lire notre méthode complète.