Migration Google Workspace vers Microsoft 365 : réussir sa transition pas à pas
Migrer de Google Workspace vers Office 365 (désormais Microsoft 365) est une décision stratégique pour de nombreuses entreprises. Après des...
Microsoft Project Online sera officiellement retiré le 30 septembre 2026.
Avant de choisir entre Planner Premium, Project Server Subscription Edition, Jira, Azure DevOps, Monday ou une autre solution PPM, l’enjeu n°1 n’est pas la migration technique, mais le diagnostic d’usage réel de l’outil au sein de votre organisation.
Fin de Microsoft Project Online : une échéance que beaucoup de DSI sous-estiment encore
Depuis plus de dix ans, Microsoft Project Online a été l’un des standards de fait du Project Portfolio Management (PPM) dans les grandes entreprises. Adossé à SharePoint, intégré à l’écosystème Office, il a structuré le pilotage de projets de milliers d’organisations, des PMO industriels aux directions de programmes IT.
En septembre 2025, Microsoft a confirmé une décision attendue depuis 2018 : Project Online sera officiellement retiré le 30 septembre 2026. Passée cette date, les projets et les données associées ne seront plus accessibles dans le service. Pour les entreprises concernées, ce n’est pas une mise à jour mineure, c’est une transformation à part entière de leur stack PPM.
Chez Synapsys, nos échanges récents avec des PMO et des DSI font remonter un constat clair : la majorité des organisations abordent ce sujet par le mauvais bout. Elles se concentrent sur la migration technique (« on bascule vers quoi ? ») avant d’avoir compris ce qui se passe vraiment dans leur Project Online actuel.
Or, le choix de la cible (Microsoft ou non, Planner Premium, Project Server SE, Jira, Azure DevOps, Monday, Trello, ou une combinaison hybride) dépend entièrement de cet usage réel.
Cet article propose une méthode de cadrage structurée, un panorama actualisé des alternatives, et les pièges à éviter dans les 12 prochains mois.
Ce que Microsoft a annoncé sur la fin de Project Online (et ce qui n’est pas concerné)
Calendrier officiel de Microsoft : les dates clés
Ce qui est concerné
Uniquement Project Online, c’est-à-dire :
- L’interface Project Web App (PWA)
- Les sites Project Web App sur SharePoint Online
- Les SKU Project Plan 3 et Plan 5 dans leur version Project Online historique
- Les personnalisations, workflows SharePoint 2013, custom fields et connecteurs propres à PWA
Ce qui n’est pas concerné
- Microsoft Project Desktop continue d’exister.
- Project Server (on-premises) : les versions 2016 et 2019 passent en support étendu en juillet 2026, et Microsoft recommande la bascule vers Project Server Subscription Edition.
- Microsoft Planner (qui regroupe désormais Planner, To Do et Project for the web) continue d’évoluer, avec une montée en charge progressive des fonctionnalités héritées de Project for the web sous l’appellation Planner Premium.
Autrement dit, Microsoft ne tue pas la planification de projet, mais condamne une architecture (PWA + SharePoint) qu’il juge incompatible avec sa stratégie « Modern Work » centrée sur Microsoft 365, Power Platform et Copilot.
Avant de migrer : comprendre l’usage réel de Project Online dans votre organisation
Project Online est une plateforme particulièrement polyvalente.
Deux entreprises qui utilisent Project Online peuvent en faire des usages radicalement différents. Et c’est précisément cette diversité d’usages qui rend toute recommandation générique dangereuse.
Les quatre axes de diagnostic à mener en priorité
Avant de comparer la moindre alternative, il faut répondre à quatre questions structurantes.
Quel est le niveau d’usage réel ?
L’utilisation oscille typiquement entre trois profils très différents :
- Usage basique : suivi de tâches, jalons, dépendances simples, sans vraie consolidation portefeuille. Souvent, une partie significative de ce qui transite par Project Online pourrait vivre dans un outil bien plus léger.
- Usage avancé : gestion des ressources, capacity planning, planning détaillé multi-niveaux, workflows d’approbation, gestion des risques structurée.
- Gestion multi-projets / portefeuille : consolidation cross-projets, priorisation stratégique, arbitrages capacitaires, reporting consolidé pour le COMEX.
Plus l’usage est avancé, plus le choix de la solution cible se restreint, et plus la marche est haute pour basculer vers un outil de type Planner ou Monday.
Quelle méthodologie sous-jacente ?
- Waterfall pur : planning prédictif, chemin critique, Gantt structuré, dépendances inter-tâches.
- Agile : sprints, backlog, vélocité, burndown.
- Hybride : portefeuille piloté en waterfall, équipes delivery en agile (le cas le plus fréquent dans les grandes organisations).
Chaque outil a une « génétique » méthodologique. Project Online est nativement waterfall ; Jira est nativement agile ; Monday est neutre mais plus à l’aise sur l’agile et l’opérationnel ; Azure DevOps est conçu pour l’ingénierie logicielle.
Choisir un outil dont la philosophie est incompatible avec celle de l’organisation, c’est garantir un échec d’adoption.
Comment sont gérés les données et le reporting ?
C’est le sujet qui coûte le plus cher en migration et que tout le monde sous-estime.
- Y a-t-il des dashboards Power BI connectés à OData Project Online ?
- Des exports vers un datawarehouse ou un outil tiers ?
- Des connecteurs custom, des API consommées par d’autres applications métiers ?
- Des rapports consommés par la direction qui dépendent de la structure de données PWA ?
Chaque connexion, chaque rapport, chaque automatisation devra être refait ou adapté. Un environnement Project Online très instrumenté en Power BI peut représenter des centaines d’heures de redéveloppement seul, indépendamment de la migration des projets eux-mêmes.
Quel est le profil des utilisateurs ?
- PMO et chefs de projet expérimentés : tolèrent des outils complexes si la valeur ajoutée est claire (capacity planning, arbitrage portefeuille). Demandent de la rigueur et de la traçabilité.
- Contributeurs occasionnels : ouvrent l’outil une fois par semaine pour mettre à jour leurs tâches. La complexité doit être quasi nulle, sinon l’adoption s’effondre.
- Sponsors et direction : ne veulent qu’un reporting clair, pas l’outil de production.
- Équipes delivery (dev, IT, métier) : veulent un outil qui s’intègre à leurs habitudes (Teams pour les uns, Git/CI pour les autres).
La proportion de chaque profil dans la base utilisateurs doit guider le choix : un outil parfait pour un PMO peut être inutilisable par des contributeurs occasionnels, et inversement.
Surdimensionnement ou sous-dimensionnement : les deux pièges à éviter
Sans ce travail préalable, on tombe dans deux pièges classiques :
- Le sur-dimensionnement : on remplace Project Online par un outil PPM ultra-puissant, alors que 70 % de l’usage réel se résumait à du suivi de tâches. Coût élevé, adoption faible.
- Le sous-dimensionnement : on bascule un environnement complexe vers Planner ou Trello pour « simplifier », et on découvre six mois plus tard que la gestion capacitaire et le reporting portefeuille sont devenus impossibles.
Dans les deux cas, le coût caché est énorme : projet de migration retardé, double exploitation, perte de confiance du PMO, retour en arrière à 18 mois.
Les meilleures alternatives à Microsoft Project Online en 2026
Une fois le diagnostic posé, on peut regarder le marché avec un œil informé. Voici les options qui sortent vraiment du lot aujourd’hui, classées par logique d’usage.
Alternatives Microsoft : Planner Premium, Project Server SE, Dynamics 365
Planner Premium (anciennement Project for the web)
C’est la cible que Microsoft pousse activement. Inclus dans Project Plan 3 et Project Plan 5, Planner Premium reprend la logique de calcul de Project tout en s’intégrant nativement à Teams, Loop, Power Automate et Copilot.
| Forces | Intégration M365 native, courbe d’apprentissage douce pour les utilisateurs déjà sur Teams, modèle de licence simple, roadmap IA active. |
| Limites | A date, Planner Premium reste en deçà de Project Online sur la gestion fine de portefeuille, le capacity planning avancé, certains scénarios de reporting consolidé. Microsoft comble progressivement le gap, mais sur le terrain, plusieurs PMO trouvent encore l’outil « plus pertinent pour des Product Owners ou des chefs de projet individuels que pour piloter un portefeuille consolidé ». |
| Cible idéale | Organisations avec un usage Project Online basique à intermédiaire, environnement 100 % Microsoft, méthodologie hybride ou orientée delivery. |
Project Server Subscription Edition
C’est la voie de continuité pour ceux qui veulent rester dans la logique PWA, mais en on-premises ou hébergé dans Azure.
| Forces | Reprend l’essentiel des fonctionnalités de Project Online côté planification avancée et capacity planning, déploiement maîtrisé, contrôle total sur les données. |
| Limites | Modèle on-premises avec sa charge d’exploitation, écosystème de plus en plus restreint, ressources expertes rares sur le marché. |
| Cible idéale | Organisations avec un usage avancé de Project Online, contraintes de souveraineté ou réglementaires fortes, ou volonté explicite de différer la transition cloud. |
Dynamics 365 (Project Operations)
Microsoft positionne aussi Dynamics 365 Project Operations sur les scénarios où le projet est étroitement lié à la facturation client, à la gestion des temps et au financier.
| Forces | Excellent pour les ESN, cabinets de conseil, organisations en mode « projet facturable », avec une vision complète de bout en bout. |
| Limites | Suite très large, parfois surdimensionnée pour un besoin PPM pur. Coût d’entrée et complexité d’implémentation élevés. |
| Cible idéale | Organisations en mode service où le projet est aussi un objet financier. |
Alternatives hors Microsoft : Jira, Azure DevOps, Monday.com, Trello
Jira (Atlassian)
Jira s’est imposé comme le standard du delivery agile, avec une montée en gamme continue côté portefeuille via Jira Premium et Jira Align.
| Forces | ADN agile, customisation très poussée des workflows, écosystème d’apps Marketplace très riche, intégration Confluence native, et désormais une couche IA (Rovo) sérieuse. |
| Limites | Courbe d’apprentissage et coût de TCO qui montent vite à l’échelle, philosophie « issue tracking » qui peut être déroutante pour un PMO waterfall classique. |
| Cible idéale | Organisations dont le delivery est majoritairement agile, contexte multi-équipes tech ou produit, besoin d’un outil unifié dev + projet. |
Cet article pourrait également vous intéresser : Microsoft 365 Copilot avec Jira et Confluence : pourquoi et comment le connecter ?
Azure DevOps
Souvent confondu avec Jira, Azure DevOps est en réalité plus engineering-centric.
| Forces | Intégration native avec l’écosystème Microsoft (Azure, GitHub, Visual Studio), coût raisonnable, excellent pour le pilotage du delivery logiciel avec traçabilité code-tâche-déploiement. |
| Limites | Peu adapté aux fonctions hors IT, faible support des scénarios PPM enterprise. |
| Cible idéale | DSI et directions techniques dont le portefeuille est essentiellement IT et où la traçabilité technique compte autant que le pilotage projet. |
Monday.com
Monday s’est positionné comme la plateforme « Work OS » polyvalente, capable d’absorber des cas d’usage très variés.
| Forces | Interface très intuitive, adoption rapide même pour les contributeurs occasionnels, dashboards visuels et configurables sans code, capacité à servir des équipes au-delà de l’IT (RH, marketing, opérations). |
| Limites | Moins puissant sur la planification waterfall complexe et le capacity planning fin, dépendance forte aux automatisations qui peuvent devenir difficiles à maintenir à grande échelle. |
| Cible idéale | Organisations multi-métiers, besoin d’un outil partagé entre IT et fonctions support, profils utilisateurs hétérogènes. |
Trello
Trello reste pertinent comme outil léger, pas comme remplaçant direct de Project Online.
| Forces | Simplicité radicale, prise en main immédiate, gratuit pour la majorité des cas. |
| Limites | Aucune capacité PPM, pas de capacity planning, reporting limité. |
| Cible idéale | Equipes individuelles ou usages très tactiques, en complément d’une autre solution. |
Tableau comparatif des alternatives à Microsoft Project Online
Pénurie d’experts Project Online : un risque sous-estimé pour votre migration
C’est un sujet rarement évoqué publiquement, mais qui pèse lourd dans les projets de migration en 2026.
Les experts qui maîtrisent réellement Project Online en profondeur (PWA, custom fields, workflows SharePoint 2013, OData, intégrations Power BI complexes, Enterprise Project Types) sont de plus en plus rares.
Microsoft a cessé de pousser la plateforme depuis plusieurs années, les certifications se sont raréfiées, et les profils qui existaient sont passés sur Modern Work, Power Platform ou d’autres écosystèmes.
Cette raréfaction a deux conséquences directes :
- La phase de cadrage est plus difficile à mener en interne. Beaucoup d’organisations ne disposent plus, en interne, des compétences nécessaires pour cartographier finement leur environnement Project Online actuel. Les schémas de données, les customisations héritées, les flux Power Automate adossés à PWA sont devenus une zone grise.
- Le coût de la migration augmente mécaniquement. Sur un marché tendu, les prestations d’audit et de migration Project Online se valorisent à la hausse. Démarrer tard, c’est non seulement risquer de manquer l’échéance, mais aussi de payer plus cher des compétences contraintes.
D’où une recommandation simple : plus le cadrage démarre tôt, plus il a de chances de bénéficier de ressources expertes disponibles à un coût raisonnable.
Plan de migration Project Online : la méthode en 5 étapes
Voici la démarche que Synapsys préconise pour les organisations qui n’ont pas encore engagé la transition.
Étape 1 : Cartographier l’existant (4 à 6 semaines)
Inventorier précisément :
- Les projets actifs, archivés, en pause
- Les Enterprise Project Types et templates utilisés
- Les custom fields et structures de données
- Les workflows SharePoint 2013 et leurs déclencheurs
- Les rapports Power BI et leurs sources OData
- Les connecteurs et intégrations tierces
- Les utilisateurs réels (et pas seulement les licences attribuées)
Cette photographie est non négociable. Sans elle, tout le reste est de l’aveuglement.
Étape 2 : Caractériser l’usage réel (2 à 3 semaines)
Sur la base de la cartographie et d’entretiens utilisateurs ciblés (PMO, chefs de projet, contributeurs, sponsors), classer l’usage selon les quatre axes vus plus haut : niveau, méthodologie, données et reporting, profils.
C’est l’étape qui transforme un « projet de migration » en « projet de transformation PPM ». Elle permet souvent de challenger des usages historiques qui ne sont plus justifiés et de simplifier la cible.
Étape 3 : Définir la cible et l’architecture (3 à 4 semaines)
À partir du diagnostic, choisir la ou les solutions cibles. Et c’est un point important : la cible peut être plurielle. De plus en plus d’organisations adoptent une logique « best of breed » :
- Planner Premium ou Project Server SE pour le pilotage portefeuille
- Jira ou Azure DevOps pour le delivery agile
- Monday pour les équipes non-IT
- Une couche de consolidation (Power BI, Tableau, ou un outil PPM dédié) pour le reporting transverse
L’enjeu est de définir une architecture cohérente, avec des règles de circulation de données claires entre les outils.
Étape 4 : Plan de migration et de change (4 à 6 semaines, puis exécution)
Bâtir un plan qui couvre :
- La migration des données projets (avec ou sans historique, selon la valeur réelle)
- La reconstruction du reporting
- La refonte des workflows
- La formation des utilisateurs et l’accompagnement du change
- Une période de double-run réaliste (pas un fantasme à deux semaines)
Étape 5 : Décommissionner Project Online avant le 30 septembre 2026
L’objectif est d’avoir basculé en production sur la nouvelle solution plusieurs mois avant l’échéance, pour disposer d’un buffer en cas d’imprévu et pour préserver l’accès aux données sources si un retour en arrière partiel s’imposait.
Migration Project Online : les 5 erreurs à éviter
Quelques signaux faibles à surveiller dans vos projets de migration :
On va juste basculer vers Planner, c’est gratuit
Sous-estimation classique. Planner Premium n’est pas Planner basique, et la simple substitution ne résoudra ni le reporting consolidé, ni la gestion de portefeuille avancée.
On regardera la migration après les vacances d’été 2026
Trop tard. Sur les environnements complexes, les projets de migration durent typiquement de 6 à 12 mois. Démarrer en juillet 2026, c’est garantir un atterrissage forcé en septembre.
On va laisser chaque BU choisir son outil
Décentralisation totale = perte de la consolidation portefeuille au niveau groupe. Si la consolidation a de la valeur aujourd’hui, elle doit être pensée dans la cible.
On va tout migrer, historique compris
La question à se poser est quel projet clos depuis trois ans est réellement consulté ? L’archive a une valeur, mais elle ne justifie pas toujours une migration coûteuse. Un export documentaire suffit parfois.
On va reproduire à l’identique l’expérience Project Online dans le nouvel outil
La pire erreur. Chaque outil a sa logique propre. Vouloir répliquer une logique PWA dans Jira ou Monday produit un Frankenstein non maintenable. Mieux vaut accepter que la transition est aussi une opportunité de repenser certains usages.
Les questions à se poser concernant la fin de Microsoft Project Online
Avez-vous une cartographie fiable et à jour de votre environnement Project Online actuel ?
Si la réponse est non, c’est l’étape à lancer immédiatement, indépendamment du choix de la cible.
Avez-vous compris l’usage réel, et pas seulement déclaré, de Project Online dans votre organisation ?
Les usages effectifs sont souvent loin des usages cibles initialement définis. Cette photographie change radicalement le choix de l’alternative.
Avez-vous sécurisé les compétences pour mener la phase de cadrage ?
En interne ou via un partenaire, c’est le facteur critique des prochains mois.
Accompagnement à la migration Project Online
Chez Synapsys, cabinet de conseil en infrastructure, nous accompagnons les DSI, PMO et directions de programmes dans cette transition. Notre approche s’appuie sur :
- Une phase de cadrage structurée centrée sur l’usage réel et non sur l’outil cible
- Une vision indépendante des alternatives, Microsoft et hors Microsoft, sans biais de revente
- Une expertise Modern Workplace et PPM qui couvre l’ensemble du spectre, de Planner Premium à Jira en passant par les architectures hybrides
- Une conduite du changement adaptée aux profils utilisateurs hétérogènes typiques des environnements Project Online
L’échéance du 30 septembre 2026 approche plus vite qu’il n’y paraît. Les organisations qui auront pris le temps de poser le bon diagnostic en 2026 seront celles qui transformeront cette contrainte en opportunité de modernisation de leur PPM.