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

À partir du 1er septembre 2026, toutes les entreprises devront être en capacité de recevoir leurs factures sous forme électronique, via une plateforme agréée par l'administration, l'obligation d'émission s'ajoutant ensuite par paliers, dès septembre 2026 pour les grandes entreprises et les ETI, au plus tard septembre 2027 pour les PME, TPE et micro-entreprises (source : impots.gouv.fr). Pour un cabinet, cette échéance déplace des flux et pousse souvent à faire évoluer l'infrastructure : changer de serveur, migrer vers le cloud, basculer de logiciel de production ou d'hébergeur.

Une migration, ce n'est jamais un simple bouton. C'est le moment où vos données et vos accès changent de place. De ce constat 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 Cegid Loop, passer d'ACD ou de Cegid Quadra à MyUnisoft, ou raccorder Pennylane. 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 les dossiers, la base de production comptable et son historique, la messagerie, les accès à l'EDI-TDFC et aux téléprocédures, le portail par lequel vos clients déposent leurs 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 ou une période creuse, 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 écritures, 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. Et si la bascule tombe en pleine campagne fiscale, la moindre indisponibilité coûte cher.

Ce qui peut mal tourner un lundi matin

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

• L'indisponibilité pendant la bascule : un maillon ne répond pas au moment de reprise, et une partie du cabinet ne peut pas produire.
• Les données non reprises : les dossiers sont là, mais l'historique des écritures, les pièces liées ou les paramétrages manquent à l'appel.
• Les accès non rétablis : l'EDI-TDFC, le portail client ou la messagerie ne repartent pas immédiatement après le changement d'environnement.
• L'absence de retour arrière : la bascule se passe mal, l'ancien système a déjà été coupé, et il ne reste 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.

Une grille de vérification avant de basculer

Ces questions ne demandent aucune compétence technique. Elles servent à décider si la bascule est prête, ou si elle mérite d'attendre.

• La fenêtre de bascule tombe-t-elle sur un moment creux de l'activité, et non en pleine campagne ou à la veille d'une échéance de dépôt ?
• Une sauvegarde fraîche a-t-elle été prise juste avant la bascule, et sa restauration déjà testée ?
• L'ancien système reste-t-il accessible en lecture le temps de vérifier que le nouveau est complet ?
• Existe-t-il un plan de retour arrière écrit, applicable si la bascule échoue ?
• Les accès à l'EDI-TDFC, au portail client et à la messagerie sont-ils testés après la bascule, pas seulement supposés fonctionner ?
• L'historique des écritures 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 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.

Ce que je fais, et ce qui reste votre décision

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 votre calendrier de production, décider s'il faut la reporter parce qu'une échéance tombe cette semaine-là, apprécier ce qu'un jour d'indisponibilité représenterait pour vos clients 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 : la capacité de votre prestataire à vous restituer vos données. En pratique, cela veut dire pouvoir repartir avec vos dossiers, vos écritures et vos pièces dans un format exploitable si un jour vous changez de prestataire ou d'outil. Recadré simplement, la réversibilité, c'est ne pas devenir prisonnier de celui qui héberge votre informatique. Cette réversibilité repose d'abord sur votre contrat et sa clause de réversibilité ; lorsque le prestataire traite des données personnelles pour votre compte, le contrat de sous-traitance doit en outre organiser leur restitution ou leur suppression en fin de prestation, comme le prévoit l'article 28.3.g du RGPD. Le droit à la portabilité de l'article 20 ne concerne, lui, que les données personnelles que la personne concernée a fournies, pas l'ensemble d'un logiciel de production. 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ù, et à quelles conditions. Une fois que l'essentiel fonctionne et que vous maîtrisez vos accès, deux critères se vérifient séparément : la localisation, un serveur ou un cloud situé en France ou dans l'Union européenne plutôt qu'un lieu que personne dans le cabinet ne saurait nommer, et le contrôle réel, qui dépend du contrat, des accès d'administration, des clés de chiffrement, des sous-traitants et de la réversibilité. La localisation ne suffit pas seule à établir le contrôle. 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

Le plus utile, si une migration est en vue, est de me faire relire le plan de bascule : je vérifie qu'il prévoit une sauvegarde fraîche testée, une fenêtre choisie hors campagne, un retour arrière écrit avec son heure limite de décision, et une recette des accès et des données après la bascule. Vous recevez un avis écrit sur ce qui manque et ce qu'il faut sécuriser avant de fixer la date, plutôt qu'une promesse de migration « sans risque » que personne ne peut tenir.

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.