Migration informatique d'un cabinet d'avocats : les vérifications avant la bascule

Le guide de sécurité numérique du Conseil national des barreaux invite chaque cabinet à identifier les données et les processus sans lesquels il ne peut plus travailler, puis à vérifier les garanties offertes par ses prestataires informatiques, dont leur capacité à restituer et à récupérer les données. C'est précisément ce qui se joue lors d'une migration : le jour où vous changez de serveur, passez au cloud, remplacez votre messagerie ou confiez votre informatique à un nouveau prestataire, ces données et ces processus critiques changent de place. De ce cadre découle une discipline simple : on vérifie avant de basculer, pas après.

Migrer, ce n'est pas seulement changer de logiciel

On associe souvent la migration à un seul geste : installer une nouvelle version de Secib, Kleos ou Jarvis. En pratique, dans un cabinet, une migration touche plusieurs briques à la fois, et rarement isolées. Il y a le serveur ou l'hébergement où vivent vos dossiers, la messagerie et son historique, les accès au RPVA et à e-Barreau, les canaux de partage de pièces, les sauvegardes, parfois l'ensemble d'un coup quand vous changez de prestataire.

Autre réalité du terrain : la bascule tombe souvent un week-end, pour ne pas interrompre le travail. Ce qui déplace tout l'enjeu sur un moment précis. Le lundi matin, chacun rallume son poste et s'attend à retrouver son environnement comme il l'avait laissé, avec ses dossiers, ses courriels, ses accès. Une migration réussie, ce n'est pas une belle démonstration le vendredi soir : c'est un cabinet qui travaille normalement le lundi, sans même remarquer que quelque chose a changé sous le capot.

Ce qui peut mal tourner un lundi matin

Quand une bascule est menée sans filet, quatre risques reviennent :

• l'indisponibilité le jour de reprise : le lundi, un maillon ne répond pas, et une partie du cabinet ne peut pas travailler ;
• les données incomplètes après bascule : les dossiers sont là, mais l'historique des échanges, les pièces liées ou les paramétrages manquent à l'appel ;
• les accès RPVA et e-Barreau non rétablis : le transport électronique vers les juridictions ne repart pas immédiatement après le changement d'environnement ;
• l'absence de retour arrière : la bascule se passe mal, et l'ancien système a déjà été coupé, donc plus rien vers quoi revenir.

Ce dernier point est le plus coûteux, parce qu'il transforme un incident rattrapable en situation bloquée. C'est aussi le plus évitable.

RTO et RPO, en français

Deux sigles reviennent dans toute migration. Traduits, ils posent deux questions simples que vous seul pouvez trancher.

Ces deux cibles se décident avec le cabinet, parce qu'elles relèvent de votre appréciation du métier et de vos délais. Elles se mettent en œuvre côté technique, parce qu'elles dictent la fréquence des sauvegardes et l'architecture de la bascule. C'est la frontière : vous fixez le seuil tolérable, je construis ce qui le tient.

La checklist : avant, pendant, après

Ces questions ne demandent aucune compétence technique. Elles servent à décider si la bascule est prête, et rien ne se coupe tant que la dernière colonne n'est pas cochée. Je les range dans les trois moments où elles se posent.

Avant la bascule

• La fenêtre de bascule tombe-t-elle sur un moment creux de l'activité, et non la veille d'une échéance de procédure ?
• Existe-t-il un plan de retour arrière écrit, applicable si la bascule échoue ?
• L'ancien système reste-t-il accessible en lecture le temps de vérifier que le nouveau est complet ?

Pendant la bascule

• Une sauvegarde fraîche a-t-elle été prise juste avant la bascule, et sa restauration déjà testée ?
• L'ancien système est-il conservé intact, prêt pour un retour arrière, tant que le nouveau n'est pas validé ?

Après la bascule

• Les accès au RPVA, à e-Barreau et à la messagerie sont-ils testés après la bascule, pas seulement supposés fonctionner ?
• L'historique des échanges et les pièces liées à chaque dossier sont-ils présents et lisibles dans le nouvel environnement ?
• Une personne du cabinet valide-t-elle, le lundi, que le travail réel est possible, avant que l'ancien système soit coupé ?

Si une de ces réponses est « je ne sais pas », c'est le point à traiter avant de fixer une date, pas après.

Le PV de recette du lundi matin

Une bascule ne se déclare pas réussie, elle se recette. Voici le procès-verbal que je fais signer une fois le cabinet capable de travailler. Chaque ligne est un test réel, pas une supposition. Tant qu'une case reste vide, l'ancien système ne se coupe pas.

Exemple de trame, à remplir dossier par dossier le jour de la reprise.

Je bascule et je teste ; vous choisissez le moment

Voici la frontière que je tiens à poser, parce qu'elle vous protège. Je planifie la bascule, je l'exécute, je prépare et je teste le retour arrière, je vérifie que les accès et les données sont bien là de l'autre côté. C'est mon métier, et c'est ce que vous êtes en droit d'attendre d'un prestataire.

En revanche, choisir le moment de la bascule au regard de vos échéances de procédure, décider s'il faut la reporter parce qu'un délai tombe cette semaine-là, apprécier ce qu'un jour d'indisponibilité représenterait pour un dossier en cours : cela reste votre décision. Je vous donne l'état technique, les risques et une recommandation de calendrier. Vous arbitrez en fonction de ce que vous seul connaissez de votre activité et de vos délais.

Le sujet de la réversibilité, en filigrane

Une migration est aussi le bon moment pour vérifier une chose que le guide du CNB met en avant : la capacité de votre prestataire à vous restituer vos données. Le fondement est d'abord contractuel : la clause de réversibilité organise la restitution de vos dossiers, courriels et pièces dans un format exploitable le jour où vous changez de prestataire ou d'outil. Lorsque l'éditeur traite des données personnelles pour le compte du cabinet, le contrat de sous-traitance doit en outre prévoir leur restitution ou leur suppression à la fin de la prestation, comme l'exige l'article 28.3.g du RGPD. Le droit à la portabilité de l'article 20 existe aussi, mais il ne vise que les données personnelles fournies, pas l'ensemble d'un dossier de cabinet : ce n'est pas le socle sur lequel se reposer. Recadré simplement, la réversibilité, c'est ne pas devenir prisonnier de celui qui héberge votre informatique. D'expérience, je recommande de faire écrire noir sur blanc, avant toute bascule, comment vous récupérez vos données le jour où vous partez.

Où atterrit votre infrastructure

Une migration déplace vos données quelque part. Autant savoir où. Une fois que l'essentiel fonctionne et que vous maîtrisez vos accès, la question de l'hébergement se pose : un serveur ou un cloud situé en France ou dans l'Union européenne, sous votre contrôle, plutôt qu'un lieu que personne dans le cabinet ne saurait nommer. Ce n'est pas un préalable à la migration, c'est une destination possible ensuite, une fois que le socle est sain.

Par où commencer

Je ne promets pas une migration « sans risque » : personne ne peut tenir cette promesse honnêtement. Ce que je peux préparer, c'est un plan de bascule qui inclut un retour arrière et une liste de vérifications à passer avant, pendant et après. Concrètement, ce plan de retour arrière fixe trois choses à l'avance : l'heure limite avant laquelle la décision de revenir à l'ancien système doit être prise, le gel des modifications pendant la fenêtre de bascule pour ne pas travailler en double, et la façon de récupérer les données saisies dans le nouvel environnement s'il faut malgré tout revenir en arrière. Vous n'êtes ainsi jamais sans issue : soit le nouveau système est validé, soit on revient à l'ancien selon une procédure écrite d'avance.

Si vous avez une migration en vue, ou un prestataire qui vous en propose une, écrivez-moi ce qui va changer, et je vous dis quelles vérifications prévoir avant de fixer la date.