Il y a une phrase que l’on entend dans presque toutes les conversations sur le changement de fournisseur d’e-mail : « oui, nous savons que nous devrions changer, mais c’est trop compliqué ».
Derrière cette phrase se cache une crainte concrète et parfaitement rationnelle. L’e-mail est le système nerveux d’une organisation. S’il tombe en panne une demi-journée, les factures s’arrêtent, les propositions s’arrêtent, les réponses aux clients s’arrêtent. Personne ne veut être la personne qui a décidé d’y toucher.
Cet article ne dira pas que la migration est simple. Il dira exactement ce qui peut mal tourner, pourquoi, et comment éviter chaque cas. Quiconque fait cela tous les jours sait que la confiance ne se gagne pas en minimisant les risques, elle se gagne en les nommant.
Les sept vrais problèmes
1. Perdre les anciens messages. C’est la crainte numéro un, et elle est légitime. Une migration mal menée peut ne copier l’historique que partiellement et laisser de côté des dossiers entiers, généralement les plus anciens ou les plus volumineux.
2. Ne pas recevoir d’e-mails pendant la bascule. Il y a un moment, lors du changement des enregistrements de routage du domaine, où une partie du monde connaît déjà le nouveau serveur et où une autre pointe encore vers l’ancien. Mal gérée, cette fenêtre produit des messages perdus ou rejetés.
3. Découvrir trop tard qu’une boîte mail manquait. Comptes de service, adresses utilisées par des systèmes automatisés, boîtes mail d’un collaborateur parti mais qui reçoit encore des communications de clients. Elles finissent toujours par apparaître, et elles figurent rarement sur la liste initiale.
4. Oublier les redirections et les règles. De nombreuses organisations ont accumulé des années de règles : les factures qui partent à la comptabilité, les formulaires du site web qui arrivent dans une boîte mail partagée, les alertes envoyées à la personne d’astreinte. Si ces règles ne sont pas recensées au préalable, on les découvre par leur absence, et toujours au pire moment.
5. Les e-mails qui commencent à partir en spam après la bascule. Changer de serveur, c’est changer l’origine technique des messages. Si les autorisations d’envoi du domaine ne sont pas mises à jour en même temps, les e-mails légitimes de l’entreprise commencent à être traités comme suspects par les systèmes destinataires.
6. Les agendas et les contacts laissés de côté. Beaucoup de gens considèrent que la migration ne concerne que les messages. Puis ils découvrent que les rendez-vous des six prochains mois et la liste de contacts de l’équipe n’ont pas suivi.
7. Les appareils de chaque personne qui cessent de fonctionner. Le serveur a changé, mais le téléphone de chaque collaborateur est toujours configuré pour l’ancien. Sans plan pour cette partie, le résultat est une semaine d’appels à l’assistance.
Comment procéder sans mauvaise surprise
Une migration bien menée repose sur un principe qui résout la moitié des problèmes ci-dessus : la source n’est jamais supprimée.
Les données sont copiées, pas déplacées. Pendant la copie, l’ancien service continue de fonctionner exactement comme avant. Si quelque chose échoue, il n’y a rien à récupérer, parce que rien n’a été détruit. C’est la première question à poser à tout prestataire, et la réponse doit être immédiate et sans détour.
À partir de là, le travail s’organise en trois phases.
Première phase : l’inventaire. Avant de copier le moindre e-mail, on recense tout. Toutes les boîtes mail, y compris celles dont personne ne se souvient. Tous les alias et toutes les redirections. Toutes les règles de filtrage pertinentes. Tous les systèmes externes qui envoient au nom du domaine, du logiciel de facturation au formulaire du site web. C’est la phase la plus fastidieuse, et celle qui détermine la réussite de tout le reste.
Deuxième phase : la copie en parallèle. Les messages, les dossiers, les agendas et les contacts sont copiés vers la nouvelle infrastructure pendant que l’ancien service reste actif. L’équipe ne remarque rien. À la fin de cette phase, il existe deux copies complètes, et la nouvelle peut être validée sereinement.
Troisième phase : la bascule du routage. Ce n’est qu’une fois la validation terminée que le routage du domaine est basculé vers le nouveau serveur. Le changement se propage sur internet en quelques heures, et pendant cette période les deux infrastructures reçoivent des e-mails. C’est pourquoi l’ancien service reste actif quelques jours de plus : pour récupérer ce qui y arrive encore.
Une remarque sur le moment de cette phase. Elle se fait de préférence en dehors des heures de pointe, et jamais à la veille d’une clôture comptable, d’une échéance judiciaire ou d’une campagne. Non pas en raison d’un risque technique, mais parce qu’une surprise se gère plus facilement un mardi matin qu’un vendredi après-midi.
La part du client
Il y a trois choses qu’aucun prestataire ne peut faire seul, et mieux vaut le savoir dès le départ.
Décider ce qui est migré. Tout l’historique n’a pas besoin de suivre. Certaines organisations emportent tout, d’autres les trois dernières années et archivent le reste. C’est une décision métier, pas une décision technique.
Donner accès au domaine. Le changement de routage se fait là où le domaine est enregistré. Si personne dans l’entreprise ne sait où c’est, ni qui détient les identifiants, c’est le premier problème à résoudre. Cela arrive plus souvent qu’on ne le pense.
Prévenir l’équipe. Un message interne, deux jours avant, qui explique ce qui va se passer et ce que chacun devra faire sur son téléphone, évite des dizaines d’interruptions.
Les questions à poser avant de signer
- Les données source sont-elles supprimées à un moment quelconque du processus ? La bonne réponse est non.
- Le service actuel continue-t-il de fonctionner pendant la migration ? Et pendant combien de temps après ?
- Qu’est-ce qui est inclus : uniquement les messages, ou aussi les agendas, les contacts, les alias et les règles ?
- Qui met à jour les autorisations d’envoi du domaine, et quand ?
- Qui accompagne l’équipe pour reconfigurer ses appareils ?
- Quel est le plan si quelque chose tourne mal en cours de route ?
Un prestataire qui répond clairement à ces six questions a déjà montré plus que n’importe quel argumentaire commercial.
Et quand migrer n’en vaut pas la peine
En toute honnêteté, l’inverse mérite d’être signalé. Si l’organisation est en pleine fusion, en plein changement de domaine ou en pleine restructuration de ses équipes, il est logique d’attendre. Migrer deux fois est pire que migrer tard.
Sinon, reporter a généralement un coût silencieux : des années de plus avec un service qui ne convient plus, davantage de dépendance à une configuration que personne ne comprend tout à fait, et un historique toujours plus volumineux à déplacer le jour où la décision finit par être prise.
La migration n’est pas le moment du risque. Le moment du risque, c’est le jour où le système actuel tombe en panne et où il n’y avait aucun plan.