Comment prévoir la réversibilité d'un outil interne ?

La réversibilité désigne votre capacité à reprendre un outil et ses données pour les confier à quelqu'un d'autre, ou pour en changer. Elle ne se discute pas au moment de la rupture, quand la relation est tendue et les délais courts. Elle s'obtient au départ, dans le contrat, et se vérifie pendant la vie de l'outil.

De quoi avez-vous besoin pour être libre ?

Ce dernier point surprend souvent : disposer du code ne suffit pas si le contrat n'autorise pas à le faire modifier. Les principes applicables sont détaillés dans l'article sur la propriété du code source.

Ce que le contrat doit prévoir

1. La liste des éléments restitués, nommés précisément, et non une formule générale.
2. Le format des données : un export lisible par un logiciel courant, documents joints compris.
3. Le délai de restitution après la demande, et la durée pendant laquelle le prestataire reste joignable.
4. Les conditions financières de l'opération, connues à l'avance plutôt que négociées au moment du départ.
5. Le maintien du service pendant la transition, pour éviter une interruption.
6. La suppression des données chez le prestataire une fois la restitution vérifiée.

Les situations qui enferment

• Des comptes ouverts au nom d'un tiers : hébergement, nom de domaine ou services techniques souscrits au nom personnel d'un développeur ou du prestataire.
• Un export partiel : les fiches sont extraites, mais pas les documents joints ni les liens entre les éléments.
• Une documentation absente, qui oblige le repreneur à reconstituer les règles par lecture du code.
• Une plateforme fermée dont on ne peut sortir ni le paramétrage ni la logique construite.
• Une dépendance au prestataire pour des gestes courants qui devraient être réalisables en interne.

Vérifier pendant le contrat, pas à la fin

Une clause de réversibilité non testée ne vaut pas grand-chose. Prévoyez des vérifications régulières :

• demander un export complet une fois par an et l'ouvrir réellement, pour constater qu'il est exploitable ;
• vérifier que le dépôt de code est accessible à l'organisation et à jour ;
• contrôler que les comptes d'hébergement et de services tiers sont bien à votre nom ;
• tenir à jour la liste des liaisons avec d'autres logiciels et des clés utilisées, souvent par API ;
• conserver une copie de la documentation en dehors des outils du prestataire.

Ces vérifications servent aussi en cas d'imprévu : cessation d'activité, indisponibilité prolongée, incident majeur.

Réversibilité des données et réversibilité technique

Les deux ne vont pas ensemble. Un outil du marché peut offrir un export de données correct sans qu'il soit question de code, puisque vous n'en possédez pas. Une application sur mesure peut au contraire donner accès au code mais rester difficile à reprendre si la documentation manque. Évaluez donc les deux dimensions selon la solution retenue, et adaptez vos exigences en conséquence.

Lorsque la reprise devient effective, les étapes à suivre sont décrites dans l'article sur la façon de reprendre une application existante.

NexSecure prévoit la réversibilité des applications qu'elle développe, dans le cadre de son offre de développement web sur mesure.