Faire entrer un nouveau prestataire sur un projet legacy ne consiste pas à transmettre un dépôt Git et quelques accès. Le vrai sujet est de rendre le système compréhensible sans masquer ses risques.
Un legacy porte rarement seulement du code ancien. Il porte des décisions passées, des contraintes métier, des contournements, des incidents, des dépendances externes et des habitudes d’exploitation.
Dans une migration application legacy vers Symfony, l’onboarding du prestataire conditionne la qualité du diagnostic, la vitesse de reprise et la capacité à éviter les mauvaises hypothèses.
Plus l’entrée est préparée, moins le prestataire découvre les zones sensibles en production, dans l’urgence ou après une correction risquée.
Pourquoi un onboarding legacy ne s’improvise pas
Un projet legacy se comprend rarement en lisant uniquement le code. Certaines règles sont dans les données, certaines dans les usages, certaines dans les procédures support et d’autres dans la mémoire des équipes.
Si l’onboarding ne capture pas ces dimensions, le prestataire peut produire vite, mais mal prioriser les risques.
Le danger des premières impressions
Un nouveau prestataire peut croire qu’un module est simple parce que le code paraît court. Puis il découvre que ce module pilote une règle critique, un export direction ou un traitement nocturne.
Le contexte vaut autant que la documentation
Une documentation ancienne peut aider, mais elle doit être confrontée aux usages réels, aux incidents récents et aux décisions encore valables.
Préparer les accès sans ouvrir trop large
Les accès doivent être prêts avant le démarrage, mais ils doivent rester maîtrisés. Un onboarding efficace combine rapidité et sécurité.
Lister les accès nécessaires
Dépôts, tickets, documentation, environnements, logs, monitoring, base de test, outils de déploiement, gestion des secrets et canaux support doivent être identifiés clairement.
Séparer lecture, test et production
Le prestataire peut avoir besoin de comprendre la production sans pouvoir y agir librement dès le premier jour. Les droits doivent progresser avec la confiance et les procédures.
Prévoir une personne responsable des accès
Si chaque accès dépend d’un interlocuteur différent, le démarrage se transforme en chasse administrative. Une personne doit piloter l’ouverture et la fermeture des droits.
Donner le contexte métier et historique
Le contexte métier permet d’éviter les corrections dangereuses. Il explique pourquoi certaines règles existent encore, pourquoi certains écrans sont conservés et pourquoi certaines données ne peuvent pas être nettoyées rapidement.
Raconter les grandes décisions
Le prestataire doit connaître les décisions structurantes : choix d’architecture, abandon d’un module, contournement assumé, règle imposée par un service ou dette acceptée temporairement.
Identifier les personnes qui savent
Les sachants métier, support, technique et exploitation doivent être nommés. Le prestataire doit savoir qui consulter selon le type de question.
Le guide Documenter un legacy avant le départ des sachants aide à préparer cette matière avant qu’elle ne disparaisse.
Cartographier architecture, données et dépendances
La cartographie technique ne doit pas être exhaustive au premier jour. Elle doit surtout montrer où se situent les risques : données, intégrations, traitements, sécurité, performance et points de reprise.
Architecture et flux
Le prestataire doit comprendre quels systèmes communiquent, quelles données circulent, quels traitements sont critiques et quels composants ne doivent pas être modifiés sans revue.
Données et source de vérité
Les bases, exports, imports, règles de synchronisation et écarts connus doivent être expliqués. Beaucoup de risques legacy se cachent dans les données.
Environnements et reproductibilité
Un environnement local ou de test fiable évite de diagnostiquer à l’aveugle. S’il n’existe pas, sa création doit devenir un chantier d’entrée.
Un audit technique d’application web peut servir de base d’onboarding quand le legacy est trop peu documenté.
Partager incidents, dettes et zones à risque
Les incidents passés racontent souvent mieux le système que les schémas. Ils révèlent les fragilités, les comportements inattendus et les procédures de reprise.
Présenter les incidents récents
Symptômes, causes, corrections, contournements et décisions associées doivent être partagés. Le prestataire comprend ainsi ce que l’entreprise considère comme critique.
Nommer les dettes assumées
Toutes les dettes ne doivent pas être traitées immédiatement. Mais elles doivent être connues pour éviter qu’un nouveau venu construise dessus sans le savoir.
Indiquer les zones interdites sans revue
Certains modules, tables, traitements ou flux doivent être modifiés uniquement avec validation. Les nommer protège le démarrage.
Choisir les premiers tickets d’apprentissage
Les premiers tickets ne doivent pas être choisis au hasard. Ils doivent permettre au prestataire de comprendre le système sans créer un risque disproportionné.
Un ticket de lecture
Il peut consister à analyser un flux, reproduire un bug, documenter une règle ou expliquer une zone du code. Le but est de vérifier la compréhension.
Un ticket de correction limitée
Une correction encadrée permet de tester les accès, les revues, les tests, la mise en production et la communication sans toucher un périmètre trop sensible.
Un ticket de documentation utile
Demander au prestataire de documenter ce qu’il découvre permet de transformer l’onboarding en amélioration durable.
Clarifier qui valide, qui arbitre et qui escalade
Un prestataire ne peut pas reprendre proprement un legacy si les circuits de décision sont flous. Il doit savoir qui valide techniquement, qui tranche métier et qui arbitre les priorités.
Validation technique
Les premières modifications doivent être relues par une personne qui connaît le système ou par un référent mandaté pour protéger l’architecture.
Arbitrage métier
Les règles ambiguës doivent être tranchées par le bon interlocuteur, pas par le prestataire seul sous pression.
Escalade run
En cas d’incident, le prestataire doit connaître les personnes à prévenir, les délais attendus, les procédures et les critères de communication.
Le guide Répartir rôles et responsabilités entre client et intégrateur aide à formaliser ces circuits.
Transformer l’onboarding en transmission durable
Un bon onboarding ne sert pas seulement au prestataire. Il doit améliorer la capacité de toute l’organisation à comprendre le legacy.
Documenter les découvertes
Chaque surprise, règle implicite, procédure manquante ou dette confirmée doit rejoindre une documentation vivante.
Partager les diagnostics
Les premiers diagnostics doivent être restitués à l’équipe interne pour enrichir la compréhension collective, pas rester dans le périmètre du prestataire.
Le guide Transmettre la connaissance d’un logiciel interne à plusieurs personnes prolonge ce point.
Guides complémentaires pour reprendre un legacy
Ces guides complètent l’onboarding par la documentation, le découpage de migration, les responsabilités et la maintenance.
Documenter les sachants
Le guide Documenter un legacy avant le départ des sachants aide à structurer le savoir avant la reprise.
Découper la migration
Le guide Migration : domaine, fonctionnalité ou utilisateur ? aide à transformer la reprise en trajectoire maîtrisée.
Clarifier la maintenance
Le guide Faut-il internaliser la maintenance d’une application sur mesure ? aide à définir le bon partage de responsabilités après l’onboarding.
Organiser les rôles
Le guide Répartir rôles et responsabilités entre client et intégrateur évite les zones grises dès le départ.
Conclusion : bien onboarder, c’est réduire le risque de reprise
L’onboarding d’un nouveau prestataire sur projet legacy doit rendre le système compréhensible, mais aussi montrer où il reste fragile.
Accès, contexte métier, architecture, données, incidents, dette, premiers tickets et responsabilités doivent être préparés avant d’attendre des résultats rapides.
Dawap accompagne les projets de migration application legacy vers Symfony et de refonte logiciel métier avec audit, onboarding technique, transmission, découpage et sécurisation du run pour reprendre un existant sans multiplier les risques.
