Reprendre une application web développée par un autre prestataire : la checklist de passation

Points clés

• Avant d'annoncer le changement, sécurisez ce qui doit vous appartenir : les dépôts de code, l'hébergement et les comptes cloud, les noms de domaine, les services tiers et les données.
• Une passation couvre cinq sujets : accès, code, infrastructure, données et connaissance. Il suffit qu'un seul manque pour qu'une reprise devienne de la rétro-ingénierie.
• Votre levier, c'est le contrat : une cession écrite des droits de propriété intellectuelle et une clause de réversibilité. Si vous n'avez ni l'une ni l'autre, négociez-les avant la fin de la relation, pas après.
• La nouvelle équipe doit commencer par un diagnostic en lecture seule : reconstruire l'application depuis le dépôt, tester une restauration de sauvegarde et renouveler tous les secrets avant de toucher à la moindre fonctionnalité.
• Ne décidez de reprendre ou réécrire qu'une fois que vous savez ce que contiennent réellement le code et la production.

Reprendre une application web, c'est transférer la responsabilité d'un système en production d'un prestataire (une agence, un freelance ou une équipe interne qui s'en va) à un autre, sans perdre le code, les données ni la connaissance de son fonctionnement. Cela arrive rarement au bon moment : le prestataire ne répond plus, les délais dérapent ou la relation s'est dégradée. Voici les étapes que nous suivons quand un client nous confie une application développée par quelqu'un d'autre. Ce guide est pratique, ce n'est pas un conseil juridique : faites relire votre contrat par un avocat si l'ancien prestataire conteste quoi que ce soit.

Sécurisez d'abord ce qui doit vous appartenir

Faites-le avant de prévenir le prestataire actuel de votre départ. L'essentiel devrait déjà être à votre nom : il s'agit de le vérifier, pas de le supposer.

Tout ce qui est encore au nom du prestataire est la première chose à rapatrier. Un dépôt peut être transféré d'un compte à un autre sans perdre son historique, ses tickets ni ses pull requests. Pour un nom de domaine détenu par le prestataire, le transfert nécessite un code d'autorisation, que les règles de l'ICANN obligent le registrar à fournir sur demande.

La checklist de passation

Une passation complète couvre cinq domaines. Demandez-les par écrit, sous forme de liste que le prestataire sortant peut cocher.

1. Accès

• Un accès administrateur à chaque compte du tableau ci-dessus, à votre nom.
• La liste de toutes les personnes et de tous les services qui ont un accès aujourd'hui, pour pouvoir le révoquer.
• Les secrets utilisés par l'application (clés d'API, mots de passe de base de données, clés de signature), transmis via un gestionnaire de mots de passe, jamais par e-mail. Ils seront renouvelés de toute façon.

2. Code

• Tous les dépôts, y compris les services annexes, les scripts, le code d'infrastructure et ce qui n'a jamais été fusionné.
• La confirmation du commit ou du tag qui tourne en production aujourd'hui.
• Des instructions de build et de déploiement qu'une personne extérieure à l'équipe peut suivre.

3. Infrastructure

• Une description des environnements (production, préproduction, développement) et de l'endroit où chacun tourne.
• La façon dont se font les déploiements : une chaîne automatisée, un script, ou l'ordinateur de quelqu'un.
• Les tâches planifiées, files d'attente, workers et tout ce qui tourne en dehors de l'application principale.
• La supervision et les alertes : ce qui existe, et qui reçoit les alertes aujourd'hui.

4. Données

• Le schéma de base de données et les migrations, et l'endroit où se trouvent les données de production.
• La politique de sauvegarde, et la date du dernier test de restauration réussi.
• Les données personnelles traitées, avec les contrats de sous-traitance correspondants, puisque le nouveau prestataire deviendra sous-traitant au sens de l'article 28 du RGPD (en anglais).

5. Connaissance

• Les bugs connus, les contournements et les zones « à ne pas toucher ».
• Les décisions qui expliquent les parties étranges : pourquoi tel service existe, pourquoi telle bibliothèque a été figée sur une version.
• Une ou deux séances de travail entre les développeurs sortants et la nouvelle équipe. Une heure d'explications évite des jours de lecture de code.

Quand l'ancien prestataire traîne ou ne coopère pas

La plupart des passations se passent bien. Quand ce n'est pas le cas, votre position dépend de ce que vous avez signé.

• Les droits de propriété intellectuelle. Le code écrit par une agence ou un freelance appartient à son auteur, sauf cession écrite à votre profit. Notre guide à qui appartient le code détaille ce que cette cession doit contenir en droit français. S'il n'y en a pas, faites-la signer avant la fin de la relation.
• La réversibilité. Une clause de réversibilité oblige le prestataire sortant à restituer les données, la documentation et l'assistance nécessaires au transfert du service. Les marchés publics informatiques prévoient cette obligation à l'article 42 du CCAG-TIC, un bon modèle pour les contrats privés.
• Les accès que vous détenez déjà. Si les dépôts et l'hébergement sont sur vos comptes, un prestataire qui ne répond plus ne peut pas vous bloquer. Sinon, commencez par les comptes qui font tourner l'application : hébergement, domaine et DNS.
• Le séquestre. Pour un logiciel dont vous avez une licence sans en être propriétaire, un dépôt auprès d'un tiers de confiance comme l'Agence pour la Protection des Programmes vous donne accès au code source si le prestataire disparaît.

Faites vos demandes par écrit, en les datant. Si la situation tourne au litige, cet historique comptera plus que n'importe quel appel téléphonique.

Les deux premières semaines avec la nouvelle équipe

Une nouvelle équipe ne doit pas modifier les fonctionnalités tant qu'elle ne sait pas faire tourner le système en sécurité. Les premières étapes sont les mêmes quelle que soit la technologie.

1. Reconstruire depuis le dépôt. Si l'application ne peut pas être construite et déployée à partir du code que vous avez reçu, il manque quelque chose, et mieux vaut le découvrir maintenant.
2. Tester une restauration de sauvegarde. Une sauvegarde qui n'a jamais été restaurée est un espoir, pas une sauvegarde.
3. Renouveler tous les secrets. Les anciens prestataires et leurs équipes ne doivent plus détenir d'identifiants valides. Sortez la configuration du code vers des variables d'environnement si nécessaire (The Twelve-Factor App explique pourquoi).
4. Inventorier les dépendances. Les frameworks et bibliothèques obsolètes, porteurs de failles connues, font partie des risques les plus fréquents dans une application héritée (OWASP A06, en anglais).
5. Mettre en place une supervision et des alertes qui arrivent à la nouvelle équipe, pour que le premier incident ne soit pas découvert par vos clients.
6. Consigner ce qui est trouvé, avec les risques classés, avant de proposer un plan.

C'est le terrain que couvre un audit technique, et c'est ainsi que commencent nos missions de reprise d'application.

Reprendre ou réécrire ?

Ne tranchez qu'une fois le diagnostic terminé. Le code hérité paraît souvent pire qu'il ne l'est, et une réécriture complète jette des années de corrections de cas particuliers que personne n'a documentés. La plupart des applications en difficulté gagnent à être reprises progressivement. Notre guide reprendre ou réécrire détaille les signaux d'alerte et la décision.

Les signaux d'alerte pendant une passation

• Le prestataire propose un fichier ZIP plutôt qu'un accès au dépôt et à son historique.
• Le code reçu ne correspond pas à ce qui tourne en production, ou personne ne sait dire quelle version est déployée.
• L'hébergement, les domaines ou les comptes de paiement sont au nom de l'agence, qui demande des frais pour les transférer.
• Les identifiants sont envoyés par e-mail ou par messagerie, ou le prestataire refuse que vous les renouveliez.
• Aucune documentation des tâches planifiées, des serveurs ou des services externes, seulement « tout est dans le code ».

Questions fréquentes

L'ancienne agence peut-elle refuser de nous donner le code ? Si les droits vous ont été cédés et que vous avez payé ce que prévoyait le contrat, refuser l'accès est un manquement que vous pouvez faire valoir. Sans cession écrite, le code appartient à son auteur en droit français, d'où l'importance de cette cession. Dans les deux cas, faites intervenir un avocat tôt si le prestataire refuse.

Combien de temps dure une passation ? Avec un prestataire coopératif et des comptes déjà à votre nom, le transfert lui-même prend quelques jours. La nouvelle équipe a ensuite besoin de temps pour comprendre le système avant de le modifier ; cette durée dépend de sa taille et de ce qui a été documenté.

Faut-il que l'ancienne et la nouvelle équipe se chevauchent ? Oui, si la relation le permet. Un court chevauchement, même quelques séances de travail, est le moyen le moins cher de transmettre ce qui n'a jamais été écrit.

Peut-on garder l'hébergement de l'ancien prestataire quelque temps ? Oui, à titre provisoire, si vous avez un accès administrateur et que les identifiants ont été renouvelés. Planifiez la migration vers vos propres comptes plutôt que de laisser la situation durer.

---

Chez FNB Solutions, les dépôts et l'hébergement restent sur les comptes du client dès le premier jour, le client est propriétaire du code et de la propriété intellectuelle, et chaque mission se termine par une maintenance ou une passation structurée. Nos conditions contractuelles sont publiques. Si vous devez reprendre une application, parlons-en.

Sources

• Transfert d'un dépôt, documentation GitHub
• Code d'autorisation, glossaire de l'ICANN
• CCAG-TIC 2021, article 42 : réversibilité et transférabilité
• Article 28 du RGPD : sous-traitant (en anglais)
• Agence pour la Protection des Programmes, dépôt et séquestre de code source
• The Twelve-Factor App : configuration
• OWASP Top 10, A06 : composants vulnérables et obsolètes (en anglais)