Reprendre un logiciel métier existant sans signer à l’aveugle

Situation fictive : lundi matin, le logiciel de commandes fonctionne, mais la personne qui le maintenait quitte le projet. La nouvelle équipe reçoit une archive du code et propose déjà une correction. Ne commencez pas par demander une date de livraison : demandez ce qu’elle peut démontrer sans dépendre de l’ancienne équipe.

Avant un engagement durable, la nouvelle équipe doit pouvoir observer le système, construire une version installable, déployer de façon contrôlée, restaurer les données et organiser la sortie. Si une preuve est bloquée, les quatre autres ne la compensent pas.

Une correction urgente peut modifier les journaux, les versions ou la base qui auraient permis de comprendre l’état initial. Sans immobiliser automatiquement l’activité, conservez les éléments utiles et nommez la personne qui autorise les changements.

Marquez chaque ligne observé, déclaré ou inconnu. Cette distinction évite qu’une phrase de l’ancien prestataire devienne, par recopie, un fait prétendument vérifié.

Nous appelons test de relève cette méthode propre au guide : pour chaque capacité, elle demande ce qui a été produit ou observé, dans quel environnement, par qui et à quelle date. Une autre personne doit pouvoir relire ou rejouer la démonstration.

Il ne suffit pas d’empiler les fichiers. Pour chaque pièce, le dossier indique qui en répond, où se trouve la version de référence et comment vérifier qu’elle fonctionne encore.

FICHE D’UNE PREUVE

Capacité concernée :
Version produite ou action observée :
Environnement et version :
Date et personne ayant exécuté :
Personne ayant relu ou reproduit :
Résultat attendu et résultat obtenu :
Écarts et inconnues :
Propriétaire de la prochaine action :
Condition d’arrêt ou de réexamen :

Le test de relève est un choix éditorial de ce guide, pas une norme ni une certification. Répondez d’après les démonstrations réellement observées. « Partiel » signifie qu’un élément existe mais que la preuve reste incomplète. « Bloqué » signifie qu’un accès, un droit ou une dépendance empêche la démonstration.

Même lorsque tout est déclaré démontré, le test répond seulement « candidat à une bascule encadrée ». La décision de production, l’audit et les validations juridique, sécurité et données restent séparés. Le test ne transmet pas vos réponses et ne demande aucune information confidentielle.

Il n’existe pas de délai universel : la séquence dépend de la criticité, des données, de l’architecture et de l’état des preuves. L’ordre ci-dessous évite surtout de modifier le système avant d’avoir montré comment le restaurer.

Avoir payé une prestation ou reçu les fichiers ne répond pas à toutes les questions de propriété intellectuelle. L’article L122-6 du Code de la propriété intellectuelle prévoit, sous réserve des exceptions de l’article L122-6-1, que le droit d’exploitation comprend notamment la reproduction, l’adaptation et la modification.

L’article L122-6-1 ne crée pas un droit universel de reprise. Il traite, dans des conditions précises, de la personne ayant le droit d’utiliser le logiciel et des actes nécessaires à cet usage selon sa destination ; l’auteur peut se réserver par contrat le droit de corriger les erreurs et fixer certaines modalités de ces actes. L’article L113-9 vise les logiciels créés par des employés dans l’exercice de leurs fonctions ou d’après les instructions de l’employeur : il ne s’applique pas automatiquement à une agence ou à un freelance.

L’article L131-3 impose de délimiter distinctement les droits transmis et d’en préciser l’étendue, la destination, le lieu et la durée.

Le changement de prestataire ne fait pas disparaître le RGPD

Si le prestataire traite des données personnelles pour le compte de l’entreprise, l’article 28 du règlement général sur la protection des données encadre la relation de sous-traitance. La fiche CNIL du 14 mars 2024 rappelle notamment le contrat, les garanties vérifiables et les conditions de restitution ou de destruction au terme de la prestation. L’article 28 prévoit, au choix du responsable du traitement, l’effacement ou le renvoi des données après la prestation, sous réserve d’une obligation légale de conservation. L’article 32 impose des mesures adaptées au risque, pas une recette identique pour tous les logiciels.

La reprise n’est pas toujours la bonne décision. L’issue dépend de la capacité la plus faible et de la possibilité de réduire le risque sans rendre l’entreprise plus captive.

Si la reprise est possible mais que le système ne peut pas évoluer sans risque acceptable, une migration par lots ou une réécriture ultérieure peut être étudiée. Ce choix demande son propre dossier de bascule ; il ne doit pas être déduit automatiquement du présent guide. Lorsque la cible est décidée, commencez par préparer la bascule vers un nouveau logiciel.

Le procès-verbal de reprise rassemble les faits issus du test de relève pour la direction, l’équipe métier, le responsable technique, le délégué à la protection des données (DPO) lorsqu’il est concerné et le conseil juridique. Aucun d’eux ne devrait avoir à relire tout l’audit pour comprendre la décision.

PROCÈS-VERBAL DE REPRISE

Méthode : test de relève — choix éditorial, pas une norme
Logiciel, périmètre et version observée :
Responsable de la décision :
Motif du changement d’équipe :
Observer — preuve / date / propriétaire / limite :
Construire — preuve / date / propriétaire / limite :
Déployer — preuve / date / propriétaire / limite :
Restaurer — preuve / date / propriétaire / limite :
Sortir — preuve / date / propriétaire / limite :
Droits, contrat et licences — avis requis / obtenu :
Données personnelles — responsable / délégué à la protection des données si concerné / inconnues :
Décision : bascule encadrée / mission limitée / report / STOP :
Condition d’arrêt :
Prochaine démonstration et propriétaire :

Si les faits manquent encore, un audit technique peut servir à cadrer les constats et les livrables à obtenir. Une fois la capacité de reprise établie, la page maintenance et évolution décrit le type de continuité qui peut être étudié. Dans les deux cas, le périmètre réel, les responsabilités et les conditions contractuelles restent à définir.

La relève établie, trois vérifications viennent immédiatement après. La reprise en main des droits d’accès traite des comptes hérités dont plus personne ne connaît le périmètre. Les contrôles de sécurité d’une application métier fixent ce qu’il faut prouver avant d’engager sa responsabilité sur l’existant. Et le plan de recette transforme la connaissance acquise en scénarios opposables.

Si la reprise débouche sur un remplacement plutôt que sur une continuité, deux dossiers prennent le relais : le cahier des charges pour figer ce qui doit être reconstruit, et le calcul du retour sur investissement pour comparer honnêtement maintenir et refaire. Le cas particulier d’une base Microsoft Access héritée est traité à part. Enfin, choisir un prestataire sur preuves évite de confier un existant mal documenté sur une simple promesse.