Reprise d’application web : la méthode, de l’état des lieux à la maintenance

Reprendre une application web écrite par une autre équipe ne commence pas par du développement. Une reprise d’application web se joue en trois temps : réunir les accès et le code, vérifier ce que l’entreprise possède réellement, puis faire auditer l’existant avant tout engagement. Voici la méthode, dans l’ordre.

Fin de contrat avec une agence, prestataire qui ne suit plus la charge, équipe interne qui se réduit, rachat d’une société et de son logiciel : les raisons de changer d’équipe sont nombreuses, la méthode reste la même. Ce guide s’adresse aux dirigeants et aux responsables de produit qui ne sont pas développeurs. Il commence par ce qu’il faut réunir avant le changement et se termine par ce qui suit une reprise réussie : une maintenance applicative suivie et documentée.

Avant le changement d’équipe : réunir ce qui permet de continuer

Une application ne se résume pas à son code. Pour qu’une autre équipe puisse la faire tourner, la corriger et la déployer, il lui faut tout ce qui l’entoure. La liste ci-dessous se réunit pendant que l’équipe sortante est encore sous contrat et disponible : ensuite, chaque élément manquant coûte du temps.

• Le dépôt de code, avec son historique. Un accès administrateur à la plateforme qui l’héberge, ou son transfert vers un compte au nom de l’entreprise. L’historique des modifications explique des choix que le code seul ne dit pas.
• L’hébergement. Les comptes du serveur ou du cloud, les accès d’administration, et la liste de ce qui y tourne : application, base de données, tâches planifiées, certificats.
• Le nom de domaine et les DNS. Vérifiez qui est titulaire du domaine et qui peut modifier la zone : c’est elle qui dirige vos utilisateurs vers l’application.
• La base de données et les sauvegardes. Où elles sont stockées, à quelle fréquence, et si une restauration a déjà été essayée.
• Les services tiers. Envoi d’e-mails, paiement, stockage de fichiers, SMS : chaque compte doit être au nom de l’entreprise.
• Les secrets. Clés d’API, variables d’environnement, certificats : ce sont eux qui manquent le plus souvent pour redémarrer ailleurs.
• La procédure de déploiement et la documentation. Même courte, même imparfaite : comment on installe le projet, comment on met en production, ce qu’il faut surveiller.

Prévoyez aussi une passation : une ou deux séances où l’équipe sortante explique l’architecture, les points fragiles et les opérations récurrentes. C’est l’information la moins chère que vous obtiendrez sur votre propre application.

À qui appartient le code ?

C’est la question que l’on se pose trop tard. En droit français, payer un développement ne vous en rend pas automatiquement propriétaire. Bpifrance Création le résume ainsi : lorsque le logiciel est développé par un prestataire externe, le donneur d’ordre ne devient pas automatiquement titulaire des droits. Un contrat de cession de droits doit être conclu explicitement, faute de quoi le prestataire reste propriétaire du code livré.

Source : Bpifrance Création, « Protection juridique d’un logiciel », qui cite parmi ses textes de référence les articles L. 112-2 et L. 113-9 du Code de la propriété intellectuelle.

Concrètement, relisez votre contrat et vos factures : la cession y figure-t-elle, et que couvre-t-elle ? Si elle manque, c’est le moment de la faire signer, avant la fin de la collaboration. La même source rappelle que la protection porte sur le code source, le code objet et la documentation lorsqu’elle est suffisamment détaillée, et qu’un dépôt auprès de l’Agence pour la protection des programmes (APP) ou de l’INPI constitue une preuve, pas un titre de propriété.

Les données personnelles changent aussi de mains

Si l’application traite des données personnelles (utilisateurs, clients, salariés), votre prestataire de développement ou votre hébergeur agit en général comme sous-traitant au sens du RGPD. L’article 28 du RGPD prévoit qu’au terme de la prestation, le sous-traitant supprime les données personnelles ou les renvoie au responsable du traitement, selon le choix de ce dernier, et détruit les copies existantes, sauf obligation légale de conservation.

Deux conséquences pratiques. Demandez par écrit à l’ancien prestataire la restitution, puis la suppression, des données et des sauvegardes qu’il détient. Et signez avec le repreneur un contrat qui encadre son accès aux données, comme le même article l’exige.

L’audit de reprise : savoir ce que l’on reprend

Un repreneur qui chiffre une maintenance sans avoir lu le code prend un risque, et vous le fait prendre. L’audit de reprise sert à remplacer les suppositions par un état des lieux, avant tout engagement.

Le premier point pèse souvent lourd : un langage ou un framework arrivé en fin de support ne reçoit plus de correctifs de sécurité, et la remise à niveau passe alors avant toute évolution.

L’audit se termine par un document que vous gardez, quel que soit le prestataire retenu ensuite : l’état de l’application, les risques classés par gravité et un plan de remise à niveau.

Reprendre l’existant ou réécrire ?

La tentation de tout refaire est forte, surtout quand le repreneur n’a pas écrit le code. C’est rarement la bonne première réponse : une application en service contient des années de règles métier qu’aucun cahier des charges ne décrit complètement.

• On reprend quand l’application rend le service attendu, que sa pile technique est encore maintenue ou peut être mise à jour, et que le code est lisible par une équipe qui connaît ces technologies.
• On remet à niveau par étapes quand le socle est daté mais sain : montée de version, ajout de tests sur les parcours critiques, remplacement progressif des parties fragiles.
• On réécrit, en tout ou en partie, quand la technologie est abandonnée, que le code ne peut plus être installé ni testé, ou que le besoin a tellement changé que l’existant ne le sert plus.

Le déroulé d’une reprise, étape par étape

• Sécuriser les accès. Transfert des comptes au nom de l’entreprise, changement des mots de passe et des clés partagés avec l’équipe sortante, vérification des sauvegardes.
• Auditer. L’état des lieux décrit plus haut, avec un plan de remise à niveau classé par priorité.
• Remettre en état de marche. Un environnement de développement et de test reproductible, un déploiement automatisé, une restauration de sauvegarde réellement essayée.
• Stabiliser et sécuriser. Les mises à jour de sécurité, les correctifs les plus urgents, la supervision. Aucune nouvelle fonctionnalité à ce stade.
• Passer en maintenance courante. Corrective, préventive et évolutive, avec un suivi des demandes que vous pouvez consulter : c’est le régime de la maintenance applicative (TMA).
• Reprendre les évolutions. Une fois l’application stable et documentée, la feuille de route du produit peut redémarrer.

L’ordre compte. Développer de nouvelles fonctionnalités sur une application que l’on ne sait ni tester ni redéployer, c’est ajouter du risque à un socle que personne ne maîtrise encore.

Choisir le repreneur : les questions à poser

Les réponses à ces questions distinguent vite une équipe habituée aux reprises d’un prestataire qui découvrira votre application en la facturant.

• Quelles applications avez-vous déjà reprises sur cette pile technique, et qui travaillera sur la mienne ?
• Commencez-vous par un audit, et que contient le document remis ?
• Le code sera-t-il hébergé sur un dépôt qui m’appartient, avec des comptes au nom de mon entreprise ?
• Comment suivrai-je les demandes, le temps passé et l’état de l’application ?
• Si nous arrêtons de travailler ensemble, que me remettez-vous, et quelle passation assurez-vous ?
• Comment la continuité est-elle assurée pendant les congés et les absences ?

Ces questions valent pour un prestataire proche de chez vous comme pour un partenaire nearshore francophone : ce qui compte, c’est que la langue, les horaires et les outils de suivi soient communs. Pour un prestataire installé hors de France, les points propres à la distance, dont l’encadrement des transferts de données, sont détaillés dans notre guide pour choisir un prestataire de maintenance nearshore.

Garder la main après la reprise

Une reprise réussie se reconnaît à ceci : le prochain changement d’équipe, s’il a lieu, sera simple. Quatre réflexes y suffisent.

• Des comptes au nom de l’entreprise : dépôt, hébergement, nom de domaine, services tiers. Le prestataire y est invité, il n’en est pas le titulaire.
• Une cession de droits écrite dans le contrat, pour le code existant comme pour les développements à venir.
• Une documentation tenue à jour : installation, déploiement, architecture, opérations récurrentes.
• Une clause de réversibilité qui décrit ce qui vous est remis en fin de contrat et l’assistance due pendant la passation.

Pour rédiger cette clause, les marchés publics offrent un modèle utile, même pour un contrat privé où rien ne l’impose. Le CCAG-TIC 2021 distingue la réversibilité (l’acheteur reprend lui-même les prestations, ou les confie à un tiers qu’il désigne) et la transférabilité (il les fait reprendre par un nouveau titulaire). Son article 38 prévoit un plan de réversibilité, annexé aux pièces du marché, qui en fixe la durée et les conditions, et dont le contenu peut comprendre les logiciels exécutables et, le cas échéant, les codes sources avec leur documentation, les fichiers de paramétrage, les scripts d’exploitation et des fichiers dans des formats documentés. Son article 42 en encadre la mise en œuvre : l’accès aux matériels et aux logiciels pendant la passation, et la sécurité des données lors du transfert. Les autres clauses à relire avant de signer sont détaillées dans notre article sur le contrat de maintenance applicative.

Enfin, un dépôt du code auprès d’un tiers de confiance, comme l’APP, date et prouve ce qui a été livré. Bpifrance Création le rappelle : ce dépôt est un élément de preuve, il ne crée pas de droits.

Questions fréquentes

Reprise d’application web : commencez par l’état des lieux

Un changement d’équipe se passe bien à condition d’agir dans l’ordre : réunir les accès et le code, vérifier ce que l’entreprise possède, faire auditer l’existant, puis stabiliser avant de faire évoluer. Ce que vous mettez en place à cette occasion (comptes au nom de l’entreprise, documentation, réversibilité) rendra le changement suivant plus simple.

Si vous confiez ensuite la maintenance à un prestataire, notre guide pour externaliser sa maintenance applicative détaille les critères de choix et les étapes. L’équipe iones réalise l’audit et la maintenance applicative d’applications existantes. Vous pouvez aussi nous écrire pour un premier échange.