Ce cas est un modèle, pas une référence
Cette page est un gabarit. Elle fixe la structure d'un cas client — contexte, problème, dispositif, résultats mesurés, retour critique — et laisse en placeholders tout ce qui relève du terrain. Bi Cloud doit y substituer une migration réellement menée, avec des chiffres relevés dans le tenant et l'accord écrit du client sur ce qui est publié. Tant que cette substitution n'a pas eu lieu, la page ne prouve rien et ne doit pas être présentée comme une référence.
Le contexte
[À COMPLÉTER : nom du client ou "un équipementier mécanique de 140 salariés"] exploite [À COMPLÉTER : nombre de sites] sites en France, dont [À COMPLÉTER : nombre d'ateliers] ateliers de production. La messagerie repose sur un serveur Exchange installé dans le local technique du siège, avec [À COMPLÉTER : nombre de boîtes aux lettres] boîtes aux lettres et [À COMPLÉTER : volume total des boîtes, en Go] de données.
L'informatique est portée par [À COMPLÉTER : profil de l'interlocuteur, ex. "un responsable informatique unique, sans équipe"]. Le parc est mixte : postes bureautiques au siège, comptes partagés en atelier, et [À COMPLÉTER : nombre d'opérateurs sans poste fixe] opérateurs sans poste attitré. C'est cette dernière population qui détermine la difficulté réelle d'une migration en usine, comme nous l'expliquons sur notre page Microsoft 365 dans l'industrie.
Le problème
Trois contraintes se cumulaient.
- Le support du serveur. Exchange Server 2016 et 2019 sont sortis du support étendu de Microsoft le 14 octobre 2025 (à vérifier à date) : plus de correctifs de sécurité publiés, donc une exposition qui augmente chaque mois.
- La disponibilité. [À COMPLÉTER : contrainte d'exploitation, ex. "production en 3×8, aucune fenêtre d'arrêt supérieure à 4 heures"].
- Les flux applicatifs. [À COMPLÉTER : liste des applications qui envoient des mails, ex. "ERP, GPAO, copieurs multifonctions, supervision"] envoyaient des messages via le serveur interne, sans inventaire à jour.
Le point de blocage n'était pas technique mais organisationnel : personne ne savait dire quels équipements et quelles applications dépendaient du serveur de messagerie. Une migration lancée sans cet inventaire coupe des flux qu'on ne découvre qu'au premier bon de livraison non envoyé.
Ce que nous avons mis en place
Nous avons commencé par deux semaines d'inventaire, avant toute action technique : relevé des connecteurs SMTP, des adresses d'expédition applicatives, des boîtes partagées réellement utilisées et des règles de transport en place. [À COMPLÉTER : nombre de flux applicatifs découverts] flux ont été identifiés, dont [À COMPLÉTER : nombre de flux oubliés] qui n'apparaissaient dans aucune documentation.
La migration elle-même a été menée en [À COMPLÉTER : nombre de lots] lots, découpés par service et non par site, pour que les collègues qui échangent le plus basculent ensemble. Chaque lot a été précédé d'un message interne rédigé avec [À COMPLÉTER : nom du service ou de la personne côté client].
Côté sécurité, l'ouverture d'une messagerie sur Internet impose un socle minimal : authentification multifacteur pour tous les comptes, blocage de l'authentification héritée, et publication des enregistrements SPF, DKIM et DMARC pour le domaine. Ce socle est détaillé dans notre page sécuriser sa messagerie contre le phishing.
Les opérateurs sans poste fixe ont reçu [À COMPLÉTER : dispositif retenu, ex. "un accès Teams sur bornes partagées avec connexion par code"], accompagné de [À COMPLÉTER : nombre de sessions de formation] sessions courtes en atelier. Le volet accompagnement est décrit sur notre page adoption et formation.
Les résultats mesurés
Les valeurs ci-dessous sont des emplacements à remplir avec des mesures relevées dans le tenant, pas des estimations.
| Indicateur | Avant | Après | Source de la mesure |
|---|---|---|---|
| Boîtes aux lettres hébergées sur site | [À COMPLÉTER : nombre] | 0 | Console d'administration Exchange |
| Comptes couverts par le MFA | [À COMPLÉTER : %] | [À COMPLÉTER : %] | Rapport d'authentification Entra ID |
| Authentification héritée autorisée | [À COMPLÉTER : oui/non] | Bloquée | Journaux de connexion Entra ID |
| Messages sortants alignés SPF/DKIM/DMARC | [À COMPLÉTER : %] | [À COMPLÉTER : %] | Rapports DMARC agrégés |
| Interruption de service pendant la bascule | — | [À COMPLÉTER : durée en minutes] | Journal d'exploitation |
| Tickets messagerie, 30 jours après | [À COMPLÉTER : nombre/mois] | [À COMPLÉTER : nombre/mois] | Outil de ticketing du client |
| Serveurs physiques encore à maintenir | [À COMPLÉTER : nombre] | [À COMPLÉTER : nombre] | Inventaire d'infrastructure |
Ce que nous ferions différemment
Deux choses ont coûté plus cher qu'elles n'auraient dû.
L'inventaire des flux applicatifs a été lancé après la signature, alors qu'il aurait dû faire partie du chiffrage. Résultat : [À COMPLÉTER : impact constaté, ex. "un décalage de trois semaines sur le planning"]. Nous intégrons désormais ce relevé à l'audit préalable, décrit sur notre page migration Microsoft 365.
Le deuxième point concerne les boîtes partagées. Nous avons migré l'existant tel quel, y compris [À COMPLÉTER : nombre de boîtes partagées inutilisées] boîtes que plus personne n'ouvrait. Reprendre ce ménage après la bascule est toujours plus long que de le faire avant, parce que l'urgence est retombée.
Enfin, l'après-migration mérite d'être cadré dès le départ : sans supervision, les paramètres dérivent en quelques mois. C'est le rôle d'un suivi régulier, présenté sur notre page infogérance Microsoft 365.
