De ToolShell à la fin du support : commencez dès maintenant votre migration SharePoint
La chaîne d’exploitation ToolShell ne représente pas simplement une vulnérabilité de sécurité supplémentaire nécessitant des correctifs. Elle marque un changement fondamental dans la manière dont les acteurs étatiques ciblent les infrastructures collaboratives sur site, avec les groupes chinois Linen Typhoon et Violet Typhoon ayant compromis avec succès des serveurs SharePoint pour voler des clés de chiffrement et établir un accès réseau persistant. Cette campagne d’exploitation active, combinée à la fin du support étendu de Microsoft prévue le 14 juillet 2026, impose un calendrier resserré que la plupart des organisations sous-estiment largement.
Le calcul est simple mais implacable. Une migration réaliste de SharePoint nécessite 12 à 18 mois, de l’évaluation initiale au déploiement final. Avec seulement 20 mois restants avant la fin du support en novembre 2025, les organisations qui repoussent la planification au-delà de ce trimestre devront prendre des décisions précipitées, faire face à des contraintes budgétaires ou se retrouver à exploiter une infrastructure non supportée tout en tentant de migrer dans l’urgence. Cet article propose un calendrier jalonné prenant en compte les cycles budgétaires, la complexité de l’évaluation des fournisseurs et les réalités de la migration — et non les projections optimistes des éditeurs.
Résumé Exécutif
Idée principale : Réussir la migration depuis SharePoint sur site avant la date limite de support du 14 juillet 2026 impose de démarrer immédiatement la planification, en suivant une approche structurée en cinq étapes sur 12 à 18 mois. Les organisations doivent intégrer les cycles budgétaires, l’évaluation approfondie des fournisseurs, le déploiement progressif et l’adoption par les utilisateurs — des éléments du calendrier qui ne peuvent être compressés sans risquer la sécurité, la conformité et la continuité opérationnelle.
Pourquoi c’est important : Les organisations qui débutent la planification de leur migration SharePoint fin 2025 ou début 2026 devront faire des choix impossibles : bâcler les phases critiques d’évaluation et de planification, accepter des failles de sécurité lors de migrations précipitées, ou exploiter une infrastructure vulnérable et non supportée pendant la transition. La convergence de l’exploitation active de ToolShell et de l’échéance du support supprime tout luxe d’attendre le prochain cycle budgétaire ou de retarder la prise de décision.
Résumé des points clés
- ToolShell révèle une faille architecturale : Cette chaîne d’exploitation visant SharePoint sur site (CVE-2025-53770, CVSS 9.8) illustre des tactiques étatiques sophistiquées permettant de voler des clés de chiffrement pour un accès persistant, des vulnérabilités que les correctifs seuls ne peuvent corriger dans une architecture sur site héritée.
- La migration nécessite au minimum 12 à 18 mois : Les organisations sous-estiment systématiquement la durée de migration de 6 à 12 mois, négligeant la collecte des besoins, l’évaluation des fournisseurs, la validation de conformité, le déploiement progressif et l’adoption par les utilisateurs dans des environnements distribués.
- Les cycles budgétaires accentuent la pression sur le calendrier : Sans allocation budgétaire pour l’exercice 2026, le lancement du projet se fera mi ou fin 2026, repoussant la finalisation en 2027 ou au-delà — bien après la date limite du 14 juillet 2026.
- Cinq étapes clés ne peuvent être compressées : Évaluation et recueil des besoins, sélection des fournisseurs, planification et conception, déploiement pilote et migration en production nécessitent chacun un délai précis pour réussir sans créer de failles de sécurité ou de perturbations opérationnelles.
- Démarrer en novembre 2025 est déjà tard : Avec 20 mois avant la date limite et 12 à 18 mois nécessaires à la migration, les organisations qui commencent maintenant disposent d’une marge minime pour gérer les imprévus ou retards.
Comprendre ToolShell : pourquoi cela change la donne pour la migration
ToolShell se distingue des vulnérabilités classiques par son ampleur et son objectif. Des groupes étatiques chinois ont développé cette chaîne d’exploitation spécifiquement pour cibler les installations de SharePoint Server, exploitant des failles critiques telles que CVE-2025-53770, CVE-2025-53771, CVE-2025-49704 et CVE-2025-49706. La sophistication de l’attaque réside non seulement dans la compromission initiale, mais aussi dans sa capacité à voler des clés de chiffrement, assurant ainsi un accès persistant qui peut survivre aux cycles de correctifs.
Pour les équipes de sécurité, il s’agit d’un problème fondamental. Les architectures de sécurité zero trust traditionnelles partent du principe que la compromission est inévitable et limitent les mouvements latéraux par une vérification continue. SharePoint sur site, conçu à l’ère de la sécurité périmétrique, ne bénéficie pas de ces protections architecturales. Même les organisations dotées de capacités de réponse aux incidents rigoureuses restent exposées entre la divulgation d’une faille et l’application effective des correctifs dans des environnements complexes.
Le ciblage des plateformes collaboratives par des acteurs étatiques suit une logique claire. Ces systèmes hébergent des données à forte valeur ajoutée : contrats, propriété intellectuelle, communications sensibles. Un serveur collaboratif compromis offre aussi un point d’appui pour des mouvements latéraux vers d’autres ressources réseau. Les organisations ne peuvent pas simplement corriger des failles architecturales qui rendent ces systèmes attractifs et stratégiques.
Le vrai calendrier de migration : cinq étapes clés
Étape 1 : Évaluation et recueil des besoins (mois 1 à 3)
La réussite d’une migration repose sur une documentation rigoureuse des besoins, une étape que les organisations bâclent ou ignorent trop souvent. Cette phase exige une évaluation des risques de sécurité de l’infrastructure SharePoint existante, une cartographie des exigences de conformité aux référentiels applicables, une classification et une analyse de la sensibilité des données, une documentation des flux métiers par département, et l’implication des parties prenantes IT, sécurité, conformité et métiers.
Compresser cette phase conduit inévitablement à découvrir des besoins oubliés en cours de migration, nécessitant des ajustements coûteux ou des ajouts d’outils après coup. L’objectif n’est pas seulement un cahier des charges, mais une vision claire de ce que doit accomplir le remplaçant de SharePoint en matière de sécurité, de conformité et d’opérations. Pour les secteurs réglementés, cela inclut la cartographie des exigences CMMC, HIPAA, RGPD ou autres référentiels pertinents.
Étape 2 : Évaluation et sélection des fournisseurs (mois 3 à 6)
L’évaluation des fournisseurs va bien au-delà de la lecture de brochures ou de la participation à des démonstrations. Il faut mener des tests de preuve de concept avec des données et des flux réels, valider les approches d’architecture de sécurité, vérifier la prise en charge des référentiels de conformité, analyser le coût total de possession (y compris les coûts cachés d’exploitation), et négocier des contrats intégrant un support et des SLA adaptés.
La question clé n’est pas « cette plateforme fait-elle ce que fait SharePoint », mais « cette plateforme résout-elle les problèmes qui nous poussent à quitter SharePoint ». Les solutions proposant une architecture de réseau de données privé, des principes zero trust, une autorisation FedRAMP Moderate et une gouvernance unifiée sur le partage de fichiers, l’e-mail et le transfert sécurisé de fichiers incarnent une approche radicalement différente d’une simple migration SharePoint vers un cloud mutualisé.
Étape 3 : Planification et conception (mois 6 à 9)
La planification de la migration conditionne la réussite ou la transformation du projet en crise prolongée. Cette phase consiste à élaborer une méthodologie détaillée de migration, incluant le choix d’une approche progressive, la conception de l’architecture de sécurité et la configuration des référentiels de conformité, l’intégration avec les systèmes existants, la cartographie des accès et autorisations, la création de programmes de formation et de communication, ainsi que l’identification des groupes pilotes avec définition des critères de succès.
Le livrable n’est pas un simple plan projet, mais un schéma directeur couvrant l’architecture technique, la validation sécurité et conformité, la communication et la formation des utilisateurs, ainsi que la gestion des imprévus. Les organisations qui bâclent cette étape subissent des interruptions prolongées, de la confusion utilisateur, des failles de sécurité et doivent parfois recommencer certaines migrations.
Étape 4 : Déploiement pilote et validation (mois 9 à 12)
Le déploiement pilote auprès de 50 à 200 utilisateurs permet de valider la stratégie de migration avant tout impact organisationnel majeur. Cette phase vérifie le bon fonctionnement des flux métiers réels, l’application des politiques de sécurité, la traçabilité des données pour la conformité, et l’adoption utilisateur.
Les enseignements du pilote servent directement à ajuster la migration en production. Les problèmes identifiés et résolus à ce stade sont autant d’écueils évités lors du déploiement à grande échelle. Les organisations qui négligent ou précipitent le pilote découvrent ces problèmes au pire moment, allongeant les délais et sapant la confiance dans la migration.
Étape 5 : Migration en production (mois 12 à 18)
La migration en production s’effectue par vagues, et non en un seul basculement. Les départements pionniers migrent d’abord pour valider les procédures, suivis des groupes standards, puis des groupes complexes ou sensibles qui bénéficient des retours d’expérience. Chaque vague nécessite supervision, support, résolution des incidents et validation avant de poursuivre.
Cette approche progressive laisse le temps aux utilisateurs de s’adapter, permet de résoudre les problèmes sans pression de crise, et garantit que tout fonctionne avant la mise hors service des anciens systèmes. Un calendrier compressé entraîne résistance utilisateur, contournements des règles de sécurité et failles potentielles dans la gouvernance des données.
La réalité du calendrier : attendre, c’est rater la date limite
Les mathématiques de la migration sont sans appel. Nous sommes en novembre 2025. La fin du support Microsoft est fixée au 14 juillet 2026 — soit environ 20 mois. Un calendrier réaliste s’étale sur 12 à 18 mois. Les organisations qui commencent maintenant disposent de 2 à 8 mois de marge pour gérer les imprévus. Celles qui attendent le premier trimestre 2026 n’ont plus aucune marge. Celles qui attendent l’allocation budgétaire de l’exercice 2027 rateront complètement la date limite.
Les contraintes budgétaires accentuent cette pression. Sans budget dédié à la migration SharePoint pour l’exercice 2026, il faudra planifier et obtenir l’approbation pour 2027, ce qui reporte le lancement à mi ou fin 2026. Cela décale la finalisation en 2027 ou 2028, obligeant à exploiter une infrastructure non supportée pendant la migration.
Chaque mois de retard accroît l’exposition aux exploits comme ToolShell, réduit le temps disponible pour évaluer les fournisseurs, et augmente le risque de décisions précipitées sous pression. Les organisations qui s’y prennent tard devront aussi composer avec des fournisseurs saturés, le marché se ruant pour migrer avant la date limite.
Mesures de sécurité transitoires : nécessaires mais insuffisantes
Pendant la planification de la migration, il convient de renforcer la sécurité de l’infrastructure SharePoint existante. Appliquez les correctifs dès leur publication, segmentez le réseau pour limiter les mouvements latéraux depuis les serveurs SharePoint compromis, améliorez la surveillance des indicateurs ToolShell et des comportements d’authentification inhabituels, renforcez les contrôles d’accès avec l’authentification multifactorielle, et augmentez la fréquence des sauvegardes avec des tests réguliers de restauration.
Ces mesures transitoires réduisent le risque mais n’éliminent pas les failles architecturales qui rendent les plateformes collaboratives sur site si attractives. Elles constituent une réduction temporaire du risque, pas une stratégie de sécurité pérenne. Il faut accélérer la planification de la migration plutôt que de s’appuyer indéfiniment sur ces contrôles.
Kiteworks : votre solution de migration SharePoint
Les organisations à la recherche d’alternatives à SharePoint font face à un choix stratégique : migrer vers SharePoint Online et hériter de nombreuses limites de conformité dans une architecture mutualisée, ou opter pour une plateforme conçue pour résoudre les problèmes qui motivent la sortie de l’infrastructure sur site.
Kiteworks propose un réseau de données privé avec une architecture zero trust qui élimine la surface d’attaque exploitée par les acteurs étatiques sur les plateformes sur site. Contrairement au modèle mutualisé de SharePoint Online, Kiteworks offre une infrastructure logiquement isolée, incluant un cloud privé virtuel autorisé FedRAMP Moderate (depuis juin 2017) et FedRAMP High Ready (depuis février 2025), garantissant un niveau de sécurité rarement égalé.
La gouvernance unifiée de la plateforme répond à une limite majeure de SharePoint : la fragmentation de la sécurité sur plusieurs canaux d’échange de données. Kiteworks centralise les canaux de communication de données, dont le partage sécurisé de fichiers, la messagerie sécurisée, le MFT, Kiteworks SFTP et les formulaires de données sécurisés, sous des politiques et journaux d’audit centralisés, supprimant la lourdeur de la conformité liée à la corrélation de données entre systèmes disparates.
Pour les équipes conformité, Kiteworks automatise ce que SharePoint impose de faire manuellement. La plateforme couvre près de 90 % des exigences CMMC 2.0 Niveau 2 pour les sous-traitants de la défense, propose des référentiels préconfigurés pour la conformité HIPAA, PCI DSS, RGPD, PCI, CMMC 2.0 et ITAR, et fournit un reporting d’audit automatisé 90 % plus rapide que les processus manuels SharePoint selon les retours clients.
L’impact mesurable est décisif pour justifier le budget. Les organisations qui migrent vers Kiteworks constatent une réduction de 75 % des incidents de sécurité liés à l’échange de données sensibles, un reporting de conformité 90 % plus rapide qu’avec SharePoint sur site, et une baisse de 60 % du coût total de possession grâce à l’élimination des coûts matériels, à la réduction de la charge opérationnelle sécurité et à la réaffectation des ressources IT.
Mais surtout, pour celles qui font face à l’échéance de juillet 2026, Kiteworks propose une méthodologie de migration éprouvée sur des milliers de projets. Notre équipe dédiée accompagne chaque étape avec une approche progressive qui limite les perturbations tout en maximisant les gains de sécurité. Ce soutien structuré aide à respecter des délais serrés sans sacrifier les exigences ni créer de failles de sécurité.
La pression du calendrier est réelle, mais la solution est claire. Découvrez comment Kiteworks peut vous aider à réussir une migration SharePoint jalonnée, dans les temps, tout en comblant les failles de sécurité, de conformité et de gouvernance que l’infrastructure sur site ne peut plus résoudre. Planifiez une consultation pour examiner votre calendrier et vos besoins spécifiques.
Foire aux questions
ToolShell est une chaîne d’exploitation développée par les groupes étatiques chinois Linen Typhoon et Violet Typhoon, ciblant des vulnérabilités critiques de SharePoint Server, notamment CVE-2025-53770 (CVSS 9.8), CVE-2025-53771, CVE-2025-49704 et CVE-2025-49706. Ces exploits permettent aux attaquants de compromettre les serveurs SharePoint et de voler des clés de chiffrement, offrant ainsi un accès réseau persistant même après correction de la faille initiale. Les serveurs SharePoint sont des cibles de choix car ils contiennent des communications sensibles, des contrats, de la propriété intellectuelle et servent de points d’appui pour des mouvements latéraux vers d’autres ressources réseau. L’exploit démontre que les plateformes collaboratives sur site présentent des failles architecturales que les correctifs seuls ne peuvent corriger, car ces systèmes ont été conçus à l’ère de la sécurité périmétrique, et non selon une architecture zero trust qui part du principe de compromission et limite les mouvements latéraux.
Une migration SharePoint réaliste s’étale sur 12 à 18 mois, de l’évaluation initiale au déploiement en production, soit bien plus que les 6 à 9 mois souvent supposés. Ce calendrier comprend l’évaluation et la collecte des besoins (mois 1 à 3), l’évaluation et la sélection des fournisseurs avec tests de preuve de concept (mois 3 à 6), la planification et la conception détaillées incluant l’architecture de sécurité et la configuration des référentiels de conformité (mois 6 à 9), le déploiement pilote et la validation avec un sous-ensemble d’utilisateurs (mois 9 à 12), puis la migration progressive en production (mois 12 à 18). Les organisations sous-estiment systématiquement ces délais car elles négligent les cycles d’approbation budgétaire, l’évaluation approfondie de la sécurité des alternatives, la validation des référentiels de conformité, la formation et l’adoption utilisateur, et le fait qu’une migration à grande échelle ne peut être précipitée sans créer de failles de sécurité ou de perturbations opérationnelles. Des plateformes comme Kiteworks, avec des méthodologies éprouvées et des équipes dédiées, aident à respecter ces délais, mais même avec un excellent accompagnement, la gestion du changement et les validations requièrent des durées incompressibles sous peine de risques majeurs.
Continuer à utiliser SharePoint sur site après la date limite du 14 juillet 2026 expose à des risques croissants et cumulatifs. Les vulnérabilités découvertes après cette date ne seront plus corrigées, laissant vos systèmes exposés à des exploits documentés sans solution. Les référentiels de conformité exigent de plus en plus des mises à jour régulières pour les systèmes traitant des données sensibles, rendant difficile, voire impossible, de prouver la conformité avec un logiciel non supporté — ce qui impacte particulièrement les organisations soumises au CMMC, à l’HIPAA, au PCI DSS ou à des référentiels similaires. Les assurances cyber excluent généralement les incidents impliquant des logiciels non supportés, exposant financièrement les organisations. Sur le plan opérationnel, les problèmes de compatibilité avec les nouveaux systèmes et outils de sécurité s’accumuleront, rendant la migration ultérieure plus complexe et coûteuse. Il faut considérer juillet 2026 non comme un objectif lointain, mais comme la date limite absolue, et commencer l’évaluation et la planification dès maintenant pour éviter d’exploiter une infrastructure vulnérable, non supportée et potentiellement non conforme.
Ce choix dépend de la capacité de SharePoint Online à résoudre les problèmes qui motivent la sortie de l’infrastructure sur site. SharePoint Online élimine la maintenance matérielle mais fonctionne dans une architecture mutualisée où vos données partagent l’infrastructure avec des milliers d’autres organisations, ce qui peut ne pas répondre aux exigences de sécurité pour les données très sensibles. Il hérite aussi de nombreuses limites de conformité de la version sur site, comme l’absence d’automatisation du reporting d’audit, de traçabilité complète des données et de gouvernance unifiée sur l’e-mail, le partage de fichiers et les autres canaux d’échange. Les organisations ayant des exigences élevées en matière de sécurité ou de conformité constatent souvent que des plateformes spécialisées dans l’échange sécurisé de données répondent mieux à leurs besoins. Des solutions comme Kiteworks proposent une architecture de réseau de données privé, une infrastructure logiquement isolée, une autorisation FedRAMP Moderate, la prise en charge de près de 90 % des exigences CMMC 2.0 Niveau 2, et une gouvernance unifiée sur tous les canaux de circulation des données sensibles. Le bon choix dépend de vos exigences d’architecture de sécurité, de conformité et de la nécessité ou non de centraliser le transfert sécurisé de fichiers, la sécurité des e-mails et le partage de fichiers sous des politiques et journaux d’audit unifiés.
Les erreurs les plus fréquentes et coûteuses lors de la planification d’une migration SharePoint sont : sous-estimer les délais de 6 à 12 mois, négliger les cycles et processus d’approbation budgétaire, ignorer la collecte approfondie des besoins (ce qui entraîne des changements de cap en cours de migration), précipiter ou ignorer le pilote qui aurait permis d’identifier les problèmes avant un impact global, et tenter un basculement « big bang » au lieu d’une migration progressive permettant validation et résolution des incidents. Les organisations omettent aussi souvent de cartographier les exigences de conformité, découvrant les écarts seulement lors d’audits post-migration. Une autre erreur critique consiste à évaluer les plateformes uniquement sur la liste des fonctionnalités, au lieu de s’intéresser à l’approche architecturale en matière de sécurité et de gouvernance — se demander « peut-elle faire ce que fait SharePoint » au lieu de « résout-elle les problèmes qui nous poussent à quitter SharePoint ». Beaucoup sous-estiment aussi l’importance de la gestion du changement et de la formation des utilisateurs, ce qui conduit à des contournements des contrôles de sécurité. Enfin, il arrive que la validation de la capacité de la plateforme choisie à répondre aux besoins spécifiques de gouvernance des données, de sécurité zero trust et d’automatisation de la conformité soit négligée avant de s’engager, révélant les limites après un investissement conséquent en temps et en budget.
Ressources complémentaires
- Article de blog
5 meilleures solutions de partage sécurisé de fichiers pour les entreprises - Article de blog
Comment partager des fichiers en toute sécurité - Vidéo
Kiteworks Snackable Bytes : Partage sécurisé de fichiers - Article de blog
12 exigences fondamentales pour un logiciel de partage sécurisé de fichiers - Article de blog
Options de partage sécurisé de fichiers les plus fiables pour les entreprises et la conformité