Retour d’expérience : accompagner la modernisation d’un écosystème de messagerie critique

Dans les organisations publiques comme dans les grandes entreprises, la messagerie n’est jamais un simple outil d’envoi et de réception d’e-mails. Elle est un socle opérationnel, un point de convergence entre identité numérique, sécurité, collaboration, continuité de service, mobilité, gouvernance documentaire et souveraineté.

Chez MAKEHITEC, nous avons récemment mené une mission d’analyse et de cadrage autour d’un écosystème de messagerie, d’agendas et de contacts à forte criticité opérationnelle. Ce projet, réalisé dans un contexte exigeant, nous a permis de mobiliser l’ensemble de nos expertises : architecture applicative, cybersécurité, protocoles de messagerie, IAM, analyse de code, gouvernance, conduite du changement et aide à la décision.

Sans entrer dans des détails techniques ou organisationnels confidentiels, cet article revient sur les grands enseignements de cette mission et sur la valeur que peut apporter une approche rigoureuse, indépendante et structurée lorsqu’il s’agit de moderniser une plateforme de collaboration critique.

---

Une messagerie critique ne se résume pas à un webmail

La première leçon de cette mission est simple : dans un grand SI, la messagerie est rarement un composant isolé.

Elle s’appuie généralement sur une combinaison de services : serveurs SMTP, services IMAP, annuaires LDAP, mécanismes d’authentification, SSO, PKI, clients lourds, applications mobiles, webmail, agendas, contacts, outils d’administration, sauvegardes, supervision et mécanismes de délégation.

La complexité ne vient pas seulement du volume d’utilisateurs ou du nombre de boîtes. Elle vient surtout de la diversité des usages. Une même plateforme doit souvent gérer :

• des boîtes nominatives associées à des utilisateurs ;
• des boîtes partagées utilisées par des équipes ou des unités ;
• des boîtes temporaires créées pour des événements ou des missions ;
• des agendas personnels, collectifs ou délégués ;
• des accès depuis plusieurs frontaux : webmail, clients lourds, terminaux mobiles ;
• des exigences fortes en matière d’authentification, de confidentialité, de traçabilité et de continuité de service.

Une analyse sérieuse doit donc aller au-delà de la question : “Quel produit choisir ?”. La vraie question est plutôt : quel modèle d’architecture permet de couvrir durablement les usages, les contraintes de sécurité, les exigences d’exploitation et les besoins de souveraineté ?

---

Une analyse fonctionnelle fine avant toute recommandation technique

Nous avons commencé par une analyse approfondie des usages métier. Cette phase est fondamentale, car elle permet d’éviter deux erreurs fréquentes : choisir une solution sur la seule base d’une liste de fonctionnalités marketing, ou comparer des produits sans comprendre les usages réels.

L’étude a notamment porté sur les besoins de messagerie, d’agenda et de contacts, avec une attention particulière portée aux scénarios sensibles : boîtes partagées, délégations, droits par dossier, événements privés, partage de calendriers, mobilité, impression d’agendas, synchronisation multi-appareils et gestion des changements d’affectation.

Cette approche nous a permis de formaliser des matrices de couverture fonctionnelle par domaine :

• mailing ;
• agenda ;
• contacts ;
• administration et back-office ;
• sécurité et conformité ;
• exploitation, supervision et PRA ;
• migration et coexistence ;
• souveraineté et gouvernance.

Chaque besoin a été évalué selon son niveau de criticité, puis confronté aux capacités réelles des solutions étudiées.

---

L’architecture comme outil d’arbitrage

Dans ce type de projet, l’architecture n’est pas seulement une représentation technique. C’est un outil d’aide à la décision.

Nous avons cartographié les flux, les composants, les dépendances et les zones de responsabilité : authentification, annuaire, clients, services web, protocoles mail, services d’agenda, API d’administration, sauvegardes, supervision et intégrations externes.

Cette cartographie a permis d’identifier ce qui devait être conservé, ce qui pouvait être remplacé, ce qui devait être modernisé, et ce qui nécessitait une vigilance particulière.

Par exemple, un annuaire LDAP utilisé par plusieurs services ne peut pas être considéré comme une simple brique de la messagerie. Il devient un référentiel transverse à préserver et à intégrer proprement. De la même manière, un SSO existant basé sur OIDC/OAuth2, une PKI interne ou des mécanismes Kerberos ne sont pas des détails : ce sont des contraintes structurantes pour la cible.

Notre travail a donc consisté à raisonner en termes de trajectoire d’architecture, et non de remplacement brutal.

---

Une forte dimension cybersécurité

La mission a également comporté une analyse cybersécurité détaillée.

Nous avons étudié plusieurs dimensions :

• l’obsolescence des composants ;
• les risques liés aux forks historiques et aux écarts avec les branches amont ;
• la qualité du code applicatif ;
• les dépendances logicielles ;
• les mécanismes d’authentification ;
• les flux réseau et les protocoles exposés ;
• la gestion TLS/PKI ;
• les pratiques de patch management ;
• la couverture des tests ;
• les pipelines CI/CD ;
• les mécanismes de journalisation, d’audit et de traçabilité.

Dans une messagerie critique, une dette technique peut rapidement devenir une dette de sécurité. Une version ancienne d’un composant, une intégration développée sans tests suffisants, une API d’administration trop proche de la base de données, ou une gestion insuffisamment maîtrisée des droits peuvent créer des risques opérationnels et cyber.

Notre approche a donc consisté à relier constamment les constats techniques à leurs impacts réels : exposition aux vulnérabilités, complexité de maintenance, risque d’erreur d’administration, difficulté de retour arrière, dépendance à des compétences rares, et difficulté à garantir un niveau de service stable.

---

Une expertise protocolaire indispensable

La messagerie et l’agenda reposent sur des protocoles anciens, puissants et parfois subtils.

Une partie importante de la mission a consisté à analyser les usages et limites de protocoles comme :

• SMTP / SMTPS ;
• IMAP / IMAPS ;
• LMTP ;
• CalDAV ;
• CardDAV ;
• iTIP / iMIP ;
• Sieve ;
• LDAP / LDAPS ;
• OIDC / OAuth2 ;
• Kerberos / GSSAPI ;
• TLS / PKI ;
• S/MIME.

Ces protocoles ne sont pas interchangeables. Chacun porte une logique propre.

Un alias n’est pas une identité d’envoi. Une boîte partagée n’est pas seulement une adresse fonctionnelle. Un droit IMAP par dossier n’est pas équivalent à une délégation applicative. Un partage de calendrier n’a pas les mêmes implications selon qu’il est porté par CalDAV, par une interface web ou par un mécanisme propriétaire.

Cette compréhension fine est essentielle pour éviter les mauvaises décisions d’architecture. Elle permet aussi d’expliquer clairement aux parties prenantes pourquoi certaines solutions sont plus adaptées que d’autres à un contexte donné.

---

Une comparaison indépendante des solutions alternatives

Nous avons ensuite conduit une étude comparative de plusieurs solutions alternatives, en distinguant les approches :

• solutions groupware open source intégrées ;
• suites collaboratives souveraines ;
• assemblages de briques open source ;
• solutions éditeur avec support professionnel ;
• plateformes orientées fournisseurs de services ou opérateurs.

L’objectif n’était pas de produire un classement théorique, mais de mesurer l’adéquation réelle avec le besoin.

Les critères étudiés ont inclus :

• couverture fonctionnelle mail, agenda, contacts ;
• gestion des boîtes partagées ;
• partage et délégation de calendriers ;
• gestion des événements privés ;
• compatibilité avec les frontaux existants ;
• intégration SSO, LDAP, PKI ;
• capacité multi-domaine ;
• administration et back-office ;
• sauvegarde et restauration ;
• observabilité ;
• migration et coexistence ;
• modèle de support ;
• souveraineté et réversibilité.

Cette analyse a montré qu’une bonne solution n’est pas seulement celle qui possède le plus grand nombre de fonctionnalités. C’est celle dont le modèle d’architecture, d’administration et d’exploitation correspond réellement au contexte cible.

---

Le rôle central de la gouvernance

Un projet de modernisation de messagerie ne réussit pas uniquement par la technique. Il nécessite une gouvernance claire.

Nous avons donc travaillé sur les principes de gouvernance associés :

• définition des rôles d’administration ;
• séparation entre administration technique et administration fonctionnelle ;
• processus de création, modification et suppression des boîtes ;
• cycle de vie des boîtes partagées ;
• délégations ;
• règles de nommage ;
• gestion des identités d’envoi ;
• contrôle des droits ;
• traçabilité des changements ;
• politique de migration ;
• critères de décision et scoring.

La gouvernance est particulièrement importante pour les boîtes partagées et les calendriers délégués. Ces objets ne sont pas seulement techniques ; ils traduisent des responsabilités métier. Une mauvaise gouvernance peut conduire à des accès excessifs, des pertes de traçabilité, des conflits d’usage ou des difficultés d’exploitation.

---

Une démarche de transformation structurée

Pour cadrer la trajectoire de transformation, nous avons appliqué une démarche d’architecture structurée, inspirée des bonnes pratiques TOGAF : état existant, besoins métier, exigences, risques, options cibles, trajectoires, dépendances, critères de choix et macro-plan de migration.

L’enjeu n’était pas seulement d’identifier une cible, mais de proposer une transformation réaliste.

Une modernisation réussie doit tenir compte :

• des contraintes d’exploitation ;
• de la continuité de service ;
• des données existantes ;
• des droits et délégations ;
• des clients déployés ;
• de la formation utilisateur ;
• du support ;
• des exigences cyber ;
• des fenêtres de migration ;
• des scénarios de retour arrière.

Cette approche permet de passer d’une vision produit à une vision programme.

---

L’importance de la communication et de la pédagogie

Un autre enseignement fort de cette mission est l’importance de la pédagogie.

Les sujets traités sont complexes : protocoles historiques, architectures hybrides, souveraineté, dette logicielle, sécurité, partage d’agendas, multi-domaine, délégation, clients lourds, mobilité.

Pour permettre une décision éclairée, il fallait rendre ces sujets compréhensibles à des profils variés : responsables métier, architectes, experts sécurité, exploitants, décideurs, équipes projet.

Nous avons donc produit des matrices, des schémas, des tableaux de conformité, des grilles de scoring et des synthèses exécutives permettant de comparer les solutions sans masquer la complexité.

Notre conviction est qu’un bon conseil ne consiste pas à simplifier artificiellement un problème complexe, mais à le rendre lisible, maîtrisable et décidable.

---

Une mission à forte valeur ajoutée pour MAKEHITEC

Ce projet illustre parfaitement le positionnement de MAKEHITEC : accompagner des organisations exigeantes dans des sujets où l’architecture, la cybersécurité et la compréhension métier doivent avancer ensemble.

Nous avons mobilisé des compétences avancées en :

• architecture applicative et technique ;
• analyse de SI existants ;
• cybersécurité ;
• protocoles de messagerie et de collaboration ;
• IAM et fédération d’identité ;
• analyse de code et dette technique ;
• gouvernance SI ;
• comparaison de solutions ;
• conduite de transformation ;
• communication technique et exécutive.

Cette combinaison d’expertises est essentielle lorsqu’il s’agit d’évaluer une plateforme critique et d’aider une organisation à choisir une trajectoire robuste, souveraine et réaliste.

---

Remerciements

Nous tenons à adresser nos sincères remerciements à l’ANFSI pour sa confiance, la qualité des échanges et l’excellent niveau de collaboration tout au long de cette mission.

La réussite d’une telle étude repose autant sur la compétence technique que sur la transparence, l’écoute et la capacité à confronter les hypothèses. Les équipes rencontrées ont fait preuve d’une grande disponibilité, d’une forte maîtrise de leur contexte et d’un engagement remarquable dans la recherche de la meilleure trajectoire possible.

Nous remercions également l’ensemble des interlocuteurs impliqués pour la richesse des discussions, la précision des éléments partagés et l’esprit constructif qui a guidé les travaux.

---

Conclusion

Moderniser une plateforme de messagerie, d’agenda et de contacts à forte criticité ne consiste pas à remplacer un outil par un autre. C’est un exercice d’architecture, de cybersécurité, de gouvernance et de transformation.

Il faut comprendre l’existant, qualifier les usages, évaluer les risques, comparer les solutions avec rigueur, anticiper la migration et construire une trajectoire compatible avec les contraintes métier et opérationnelles.

Cette mission confirme une conviction forte chez MAKEHITEC : les projets de modernisation les plus sensibles nécessitent une approche indépendante, structurée et pédagogique, capable de relier les choix techniques aux enjeux stratégiques.

C’est précisément dans ce type de contexte que notre expertise prend tout son sens.