Recevoir un dépôt ne revient pas à recevoir un système que l’équipe peut maintenir. Pour qu’un transfert d’un projet PHP à une équipe interne soit efficace, les personnes qui le reprennent doivent pouvoir exécuter l’application, déployer des modifications, enquêter sur les incidents et prendre des décisions en connaissance de ses limites.
La transition doit être planifiée comme une partie du travail, et non comme une réunion de clôture. Il convient de définir les capacités à transférer, les personnes qui les démontreront et la manière de vérifier que l’équipe destinataire peut les exercer. L’objectif n’est pas d’éliminer toute incertitude, mais de rendre visibles les risques, les décisions en suspens et les dépendances qui continueront à nécessiter une coordination.
Définir ce que signifie être prêt à exploiter le système
Avant de rassembler les documents, définissez ce que l’équipe interne doit pouvoir faire sans dépendre d’instructions improvisées de l’équipe sortante. Selon le système, cela peut inclure le démarrage d’un environnement local, la mise en production d’une version, la consultation des journaux, la restauration des données ou la réponse à une défaillance d’une intégration.
Traduisez ces attentes en tests observables. Par exemple, une personne de l’équipe destinataire peut déployer une modification à faible risque en suivant la procédure disponible, ou expliquer comment repérer et annuler une migration problématique. Le test doit être adapté aux autorisations et à l’environnement réels : il ne faut pas provoquer un incident en production pour démontrer l’existence d’un plan de reprise.
Il faut également préciser ce qui n’est pas inclus. Certaines opérations peuvent dépendre d’une autre équipe, d’un fournisseur ou d’une approbation de sécurité. Consignez cette dépendance et le mécanisme d’escalade ; ne la présentez pas comme une capacité déjà transférée.
Inventorier le système et ses dépendances
L’inventaire technique doit permettre de localiser les composants nécessaires au développement et à l’exploitation de l’application, ainsi que leurs responsables. Incluez au minimum :
- Code et automatisation : dépôts, branches pertinentes, configuration d’intégration continue, tâches planifiées et scripts opérationnels.
- Application : version de PHP requise, gestionnaire et fichiers de dépendances, extensions, commandes de construction et configuration par environnement.
- Infrastructure et environnements : emplacement d’exécution de chaque environnement, méthode de provisionnement et différences importantes entre les tests et la production.
- Données : moteurs utilisés, migrations, sauvegardes, restauration, conservation et données sensibles à protéger.
- Services connectés : API, messagerie électronique, paiements, stockage, files d’attente et services d’identité, avec leurs responsables et les modes de défaillance connus.
Une liste de technologies ne suffit pas. Pour chaque dépendance critique, indiquez qui l’administre, quels identifiants ou autorisations sont nécessaires, comment détecter une interruption et comment l’application se comporte lorsqu’elle ne répond plus. N’incluez pas de secrets dans des documents ou des dépôts ; indiquez où ils sont conservés et comment demander l’accès.
Documenter l’architecture, les décisions et les limites
Une documentation utile répond aux questions qui se posent pendant le travail : quel composant traite une requête ? Où une donnée est-elle validée ? Quel processus met à jour cette information ? Quelles parties ne peuvent pas être modifiées sans coordonner une migration ? Une courte cartographie des composants et des flux critiques est souvent plus pratique que de chercher à décrire chaque fichier.
Consignez les décisions importantes, avec leur contexte, les solutions envisagées et leurs conséquences. Si une intégration comporte des contraintes, si une tâche périodique n’est pas idempotente ou si une partie ancienne n’a pas de tests, indiquez-le explicitement. Distinguez les faits vérifiés des hypothèses et précisez la date de révision des informations.
Incluez également les décisions en suspens : les options disponibles, l’impact d’un report, la personne responsable de leur résolution et la date ou la condition de révision. L’équipe destinataire conserve ainsi sa capacité de décision, au lieu de voir des choix hérités présentés comme des obligations supposées.
Transférer les procédures d’exécution et d’exploitation
Documentez les opérations que l’équipe devra répéter et testez-les avec ses membres. À minima, décrivez comment préparer l’environnement local, exécuter les tests, modifier le schéma, construire et déployer, vérifier une version et procéder à un retour arrière ou à une restauration.
Une procédure doit préciser les prérequis, les autorisations, les commandes ou étapes, les résultats attendus et les signaux indiquant qu’il faut s’arrêter. Si un déploiement nécessite une migration incompatible ou une tâche manuelle, indiquez l’ordre des opérations et le risque. Décrire une option de reprise ne prouve pas qu’elle fonctionne : lorsque c’est sans danger, testez-la dans un environnement adapté et consignez le résultat, les limites et la personne qui autorise son utilisation.
Complétez les procédures opérationnelles par l’observabilité : où consulter les journaux et les métriques, quelles alertes existent, qui les reçoit et comment un signal se rattache à un flux métier. Si un risque important ne fait l’objet d’aucune alerte, consignez-le comme une lacune ; ne partez pas du principe que l’équipe entrante découvrira le problème à temps.
Vérifier les accès, la propriété et la garde des actifs
L’équipe destinataire a besoin d’autorisations effectives sur le code et les outils nécessaires, et pas seulement de la promesse d’un accès futur. Vérifiez les dépôts, la gestion des incidents, les pipelines de déploiement, le cloud, les domaines, les certificats, la supervision et les comptes fournisseurs. Vérifiez qui peut administrer les utilisateurs et rétablir l’accès si une personne quitte l’organisation.
Confirmez également la propriété et la garde des actifs concernés, notamment le code, la documentation, les domaines et les configurations. Appliquez le principe du moindre privilège : disposer d’autonomie ne signifie pas partager des identifiants personnels ni accorder des autorisations sans discernement. Utilisez des comptes nominatifs ou des mécanismes approuvés, et planifiez la rotation ou la révocation des accès de l’équipe sortante conformément aux politiques internes.
Transférer les connaissances en travaillant ensemble et vérifier la clôture de la transition
Une réunion de présentation est utile, mais ne prouve pas que les connaissances ont été transférées. Organisez des démonstrations guidées de tâches réelles et alternez les rôles : l’équipe sortante explique d’abord ; ensuite, une personne de l’équipe destinataire exécute le même flux et décrit ce qu’elle vérifie et pourquoi. Prévoyez du temps pour les questions et consignez celles qui nécessitent des recherches.
La vérification doit couvrir plusieurs types de capacités : développer et tester une modification, diagnostiquer une défaillance représentative, déployer conformément à la procédure et trouver les responsables d’une dépendance critique. Choisissez des exercices sûrs et adaptés au système. Si une tâche échoue, faites la distinction entre une lacune documentaire, un manque d’autorisations, une limite technique et un besoin de formation ; chaque cause exige une action différente.
Clôturez la transition par une liste des points en suspens indiquant leur description, leur impact, leur responsable, les mesures d’atténuation et la date de révision. L’équipe destinataire doit accepter en connaissance de cause les risques résiduels. Cette acceptation ne transforme pas une limite en risque résolu : elle consigne qui en a connaissance et comment elle sera gérée.
Liste de contrôle pour une transition complète
- L’équipe destinataire peut localiser le code, l’exécuter et lancer les tests pertinents.
- Les environnements, dépendances, processus planifiés et services externes sont inventoriés.
- Une cartographie de l’architecture, des flux critiques, des décisions et des limites connues est disponible, avec des informations pouvant être mises à jour.
- Les procédures de déploiement, de vérification, de retour arrière et de reprise précisent les responsables et les prérequis.
- Les accès nécessaires ont été testés, la propriété est clairement établie et les secrets sont conservés de manière sécurisée.
- L’équipe destinataire a effectué des tâches pratiques, et ne s’est pas contentée d’assister à des explications.
- Les risques et décisions en suspens ont des responsables, des mesures d’atténuation et une acceptation explicite.
- Un canal et une période ont été convenus pour répondre aux questions liées à la transition, avec des limites clairement définies quant à leur portée.
Le transfert est prêt lorsque l’équipe interne peut démontrer les capacités convenues et sait reconnaître quand elle a besoin d’aide. S’il manque des tests, des accès ou des responsables, la remise reste incomplète, même si toute la documentation a été partagée. Ce critère fait de la clôture une transition vérifiable et préserve l’autonomie nécessaire pour maintenir et faire évoluer le projet PHP.
