Reprise de projet
Votre application ne fonctionne plus : que vérifier avant de la reconstruire ?
Accès, code, données, parcours et déploiement : une checklist pour décider quoi réparer ou reconstruire, illustrée par la reprise de HODNOS.
La réponse en bref
Une application bloquée demande d’abord des faits : ce qui échoue, ce qui reste accessible et ce qu’il faut préserver. Ces constats permettent de choisir une réparation, une reprise ciblée ou une reconstruction.
- Récupérez les accès, le code et les données avant d’engager des changements sur l’application utilisée.
- Décidez à partir des parcours et des contraintes constatées : l’ancienneté d’une technologie ne suffit pas à justifier une réécriture.
- Prévoyez les tests, la bascule et la transmission dans le périmètre de reprise, avec des critères de validation explicites.
- ComprendreCode, accès et parcours
- SécuriserSauvegardes et versionnement
- RelancerFonctions utiles et tests
Décrivez ce qui ne fonctionne plus
Une page qui s’affiche ne prouve pas que l’application fonctionne. Un utilisateur peut voir son compte tout en étant incapable de réserver, payer ou retrouver une demande. Commencez par les actions métier : qui essaie de faire quoi, à quel moment et avec quel résultat ? Conservez un exemple reproductible et le message d’erreur, si vous en avez un.
Pour un dirigeant, cette description permet de hiérarchiser les conséquences : demandes perdues, travail manuel ou activité interrompue. Pour l’équipe technique, elle fournit un point de départ vérifiable. Distinguez une panne récente d’une fonction qui n’a jamais été opérationnelle. La réponse à une régression connue peut différer d’une reprise de produit inachevé.
Le parcours attendu
Exemple : un client choisit un créneau, confirme sa réservation et reçoit sa confirmation.
Le point de rupture
Indiquez l’étape exacte, le compte de test utilisé et le comportement observé, sans transmettre de mot de passe dans le brief.
La priorité métier
Précisez si un contournement existe et quelles opérations doivent reprendre en premier.
Retrouver ce qu’il faut pour intervenir
Le diagnostic dépend des éléments accessibles. Le code déployé peut différer de celui du dépôt ; une sauvegarde peut exister sans que sa restauration ait été vérifiée. Il faut rapprocher les sources, l’application réellement utilisée et les données. Cette étape évite de décider sur une version incomplète du projet.
Faites préciser qui contrôle chaque service et comment les accès seront transmis. Vous pouvez commencer par un inventaire sans modifier la production. Avant une intervention, convenez des sauvegardes nécessaires et de la procédure à suivre si le changement ne donne pas le résultat attendu.
- Code source disponible, dépôt Git et version correspondant à l’application déployée.
- Hébergement, domaine, certificats et procédure de déploiement identifiés.
- Base de données, fichiers utilisateurs, exports et sauvegardes localisés.
- Services tiers recensés : paiement, emails, stockage, authentification et API.
- Comptes de test, journaux d’erreur et documentation disponibles.
- Responsables des accès et conditions de transmission définis.
Réparer, reprendre une partie ou reconstruire ?
Un ancien code PHP ou un MVP construit avec un outil visuel n’est pas, à lui seul, une raison de tout refaire. La décision dépend de ce qui reste exploitable, des données à préserver, des usages attendus et de la capacité à vérifier les prochaines évolutions. Un changement de technologie doit répondre à une contrainte identifiée.
La bonne proposition explique ce qu’elle conserve, ce qu’elle remplace et pourquoi. Elle précise également les incertitudes que le diagnostic doit lever. Si le problème est encore mal compris, engager immédiatement une refonte complète rend difficile la comparaison entre le coût de la réparation et celui de la reconstruction.
| Constat à confirmer | Option à examiner | Vérification attendue |
|---|---|---|
| Une modification récente a cassé un parcours auparavant fiable | Correction ciblée ou retour à une version connue | Reproduire la panne et vérifier le parcours après correction. |
| Certains modules fonctionnent et restent accessibles | Reprise progressive des parties défaillantes | Tester les échanges entre éléments conservés et remplacés. |
| Le produit fonctionne, mais son déploiement reste manuel et fragile | Fiabilisation du déploiement et de l’exploitation | Déployer une version identifiée et préparer un retour arrière. |
| Les parcours essentiels ne sont pas exploitables et très peu de code peut être repris | Reconstruction du périmètre prioritaire | Justifier les éléments conservés et valider les données migrées. |
HODNOS : remettre en marche une plateforme après plusieurs tentatives
HODNOS met en relation des clients avec des artistes. À la reprise, les parcours essentiels de réservation, de paiement et de messagerie n’étaient plus réellement exploitables. L’application reposait sur un ancien code PHP, modifié directement par FTP sur un serveur OVH, sans versionnement sur GitHub. Plusieurs développeurs étaient intervenus sans parvenir à la remettre en fonctionnement.
CUB3 a récupéré le code, créé le dépôt Git et identifié les rares éléments utiles à la migration. La mission a ensuite porté sur la reconstruction de presque toute la plateforme : inscription, réservation, paiement, messagerie et back-office. L’infrastructure a été transférée vers AWS et décrite avec Terraform. Le web, iOS et Android ont été livrés en trois mois, avec trois membres CUB3 mobilisés.
Ce résultat porte sur une remise en fonctionnement et une livraison technique. Il ne démontre pas un résultat commercial, et trois mois ne constituent pas un délai universel de reprise. La leçon utile est la démarche : récupérer, établir les constats, choisir les éléments à reconstruire, puis vérifier les parcours essentiels.
Définissez ce que « remis en fonctionnement » veut dire
Une reprise doit aboutir à des critères que vous pouvez contrôler. Remplacer une capture d’écran par une démonstration complète du parcours permet de vérifier les étapes, les droits et les données. Faites aussi préciser les cas d’échec : paiement refusé, donnée manquante ou compte sans autorisation, selon votre produit.
La mise en ligne fait partie du travail à préparer. Arrêtez les conditions de bascule, les éventuelles interruptions, la vérification des données et la personne habilitée à décider. Le suivi après livraison doit être explicite : qui reçoit un signalement, comment il est qualifié et quel accompagnement a été convenu.
- Les parcours retenus sont démontrés avec les profils concernés.
- Les données reprises sont contrôlées selon des critères convenus.
- La version livrée et les conditions de déploiement sont identifiables.
- La bascule, les vérifications et le retour arrière sont préparés.
- Les accès, la documentation et le suivi après livraison sont transmis.
Sur le terrain
Un projet concret
Ancien PHP, modifications par FTP et absence de versionnement sur GitHub : une plateforme remise en fonctionnement, avec web, iOS et Android livrés en trois mois.
La reprise de HODNOS