SharePoint ou Drupal pour votre intranet : une comparaison honnête

Le choix entre SharePoint et Drupal pour un intranet doit partir des tâches des collaborateurs, et non d’une liste de fonctionnalités. Les équipes trouvent-elles la bonne politique interne, collaborent-elles sur des documents et accèdent-elles aux services internes sans jongler entre des outils déconnectés ? Combien coûtera la mise en œuvre de ces tâches, et qui assurera le fonctionnement de l’intranet dans la durée ?

L’utilisation de Microsoft 365 fait partie de cette réflexion, mais ne constitue pas en soi une décision sur l’intranet. Comparez la façon dont chaque mise en œuvre proposée traite vos contenus, les parcours des collaborateurs, les intégrations et les évolutions futures. Ni les licences existantes ni la liberté de conception ne devraient, à elles seules, trancher la question.

Cette comparaison examine les deux voies, y compris des points de départ basés sur Drupal comme Open Intranet.

Dans cet article :

SharePoint ou Drupal pour l’intranet : que comparez-vous vraiment ?
Quelle plateforme s’intègre à votre écosystème Microsoft 365 ?
De quelle liberté avez-vous besoin pour le design et les workflows ?
Que coûte chaque intranet au-delà des licences ?
Qui contrôle l’accès, la gouvernance et l’hébergement ?
Que vérifier selon les différents scénarios de travail ?
Comment valider le choix avant de vous engager ?

SharePoint ou Drupal pour l’intranet : que comparez-vous vraiment ?

La comparaison porte ici sur SharePoint Online au sein de Microsoft 365 face à un intranet basé sur Drupal, y compris Open Intranet. Elle ne couvre pas SharePoint Server, dont le modèle de déploiement et d’exploitation est différent.

SharePoint Online est un service géré par Microsoft. Microsoft exploite la plateforme sous-jacente, tandis que votre organisation configure les sites, les contenus, les accès et l’expérience des collaborateurs.

Drupal est un framework open source de gestion de contenu. Il donne à votre organisation le contrôle de l’application et du déploiement, mais quelqu’un doit assurer l’hébergement, la configuration, les mises à jour et le support continu.

Un produit basé sur Drupal peut changer le point de départ. Open Intranet, développé par Droptica, fournit une base pour un projet intranet au lieu d’exiger que chaque élément soit assemblé à partir de zéro. Ses fonctionnalités actuelles doivent néanmoins être confrontées à vos exigences.

Notre point de vue est transparent : Droptica développe Open Intranet sur Drupal. La comparaison ci-dessous se concentre sur les capacités, les contraintes et les responsabilités de mise en œuvre, en évaluant chaque approche à partir des mêmes tâches des collaborateurs.

Domaine de décision	SharePoint Online	Intranet basé sur Drupal
Adéquation avec Microsoft 365	Identité Microsoft, collaboration documentaire et intégrations avec les services connectés, selon la configuration et les abonnements	Connexions via des modules, des API et un travail de mise en œuvre
Expérience des collaborateurs	Pages modernes, navigation, thèmes et composants WebPart au sein de la plateforme Microsoft	Contrôle des modèles de contenu, des mises en page et du design d’interaction
Licences	Accès via les abonnements Microsoft 365 ou SharePoint éligibles ; des fonctionnalités supplémentaires peuvent être payantes	Aucun frais de licence logicielle pour Drupal core ; la mise en œuvre et l’exploitation doivent être financées
Permissions	Sites, groupes, héritage et contrôles de partage	Rôles et permissions, avec configuration ou extensions supplémentaires pour un accès granulaire aux contenus
Hébergement	Infrastructure exploitée par Microsoft dans le cadre des options de service disponibles	Infrastructure choisie par l’organisation ou son prestataire
Maintenance	Microsoft maintient le service ; les clients maintiennent la configuration et les extensions	L’organisation ou le prestataire maintient l’application, les dépendances et l’hébergement
Point de départ	Composants de collaboration et de publication configurés pour l’intranet	Framework Drupal ou point de départ prêt à l’emploi comme Open Intranet

La question utile n’est pas « Quelle plateforme a le plus de fonctionnalités ? ». C’est « Que faut-il pour réaliser nos tâches prioritaires des collaborateurs, et de quoi serons-nous responsables ensuite ? »

Quelle plateforme s’intègre à votre écosystème Microsoft 365 ?

Si vos collaborateurs utilisent Teams, Outlook et les applications Office, identifiez celles de ces activités que l’intranet doit prendre en charge. Un nom d’éditeur commun ne décrit ni le parcours complet des collaborateurs ni le travail nécessaire pour le mettre en place.

Prenez trois activités quotidiennes :

Trouver une politique interne : SharePoint peut publier des politiques sous forme de pages ou les stocker dans des bibliothèques de documents. La facilité de recherche dépend toutefois des métadonnées, de la navigation, des permissions et de la configuration de la recherche.
Ouvrir un document partagé : les bibliothèques SharePoint prennent en charge la collaboration sur les documents Office, sous réserve des accès aux applications et des licences correspondantes.
Passer de l’intranet à Teams : les pages et bibliothèques SharePoint peuvent être affichées via les intégrations Teams prises en charge. Cela ne rend pas automatiquement chaque tâche de l’intranet disponible dans Teams.

Ces capacités n’appartiennent pas toutes à SharePoint lui-même. Teams fournit des interfaces de collaboration, Microsoft Entra ID fournit les services d’identité, et d’autres services Microsoft 365 peuvent apporter des fonctions d’automatisation, d’analyse ou de conformité. Leur disponibilité dépend de vos abonnements et de votre configuration.

Drupal peut lui aussi utiliser Microsoft Entra ID pour l’authentification et se connecter à Microsoft Graph, aux systèmes RH, aux outils de ticketing et à d’autres applications. Ces connexions doivent être choisies, configurées et testées. Certaines nécessitent un développement sur mesure.

Définissez ce que signifie « intégration »

Une exigence d’intégration peut cacher des volumes de travail très différents :

Niveau d’intégration	Exemple	Point clé
Lien	Un raccourci sur la page d’accueil ouvre le système RH	Les collaborateurs quittent l’intranet ; le comportement de connexion dépend de la destination
Intégration embarquée	Une vue d’application apparaît dans une page de l’intranet	L’application source doit prendre en charge l’intégration, l’authentification et les restrictions des navigateurs
Lecture via une API	Une page affiche des informations validées provenant d’un autre système	Les permissions de l’API, la disponibilité, la mise en cache et les licences doivent être examinées
Synchronisation des données	Les fiches des collaborateurs sont copiées dans un annuaire de l’intranet	Les mises à jour, suppressions, la confidentialité et les données contradictoires nécessitent des règles explicites

L’authentification unique (SSO) n’accorde pas automatiquement l’accès aux contenus connectés. Un collaborateur connecté ne doit voir que les données et documents auxquels il est autorisé à accéder.

Pour chaque connexion, demandez ce que comprend la proposition et ce qui reste à configurer ou à développer. Posez cette question pour les deux plateformes, que la source soit Microsoft 365 ou un autre système métier. Les applications Microsoft existantes peuvent rester au cœur de l’environnement de travail sans déterminer automatiquement la plateforme intranet destinée aux collaborateurs.

De quelle liberté avez-vous besoin pour le design et les workflows ?

La liberté de conception compte lorsqu’elle facilite les tâches des collaborateurs. Elle compte moins lorsqu’une interface sur mesure ajoute des coûts sans changer la manière de travailler.

Les pages modernes, les thèmes et les composants WebPart de SharePoint sont les éléments disponibles pour construire son expérience de publication. Les extensions via le SharePoint Framework peuvent ajouter des comportements personnalisés, mais elles fonctionnent dans les limites de la plateforme Microsoft.

Drupal offre le contrôle des types de contenu, des relations, des templates et du comportement de l’application. Évaluez ce contrôle au regard des exigences à couvrir et du travail de mise en œuvre et de maintenance qu’il implique.

Testez des exigences concrètes, pas des préférences visuelles

Prenez trois exemples courants :

Une page d’accueil adaptée au rôle : SharePoint propose le ciblage d’audience pour les contenus et la navigation pris en charge. Drupal peut offrir des expériences basées sur le rôle ou le profil grâce à la configuration, à des modules ou à du code personnalisé. Dans les deux cas, des attributs fiables sur les collaborateurs sont un prérequis.
Une bibliothèque de politiques par site : SharePoint peut s’appuyer sur des bibliothèques, des métadonnées, des vues et la recherche. Drupal peut modéliser les politiques avec le site, le responsable, la date d’entrée en vigueur et les services associés. Testez ce qui se passe lorsqu’une politique s’applique à plusieurs sites.
Un annuaire des services internes à vos couleurs : évaluez si les listes, pages et composants WebPart de SharePoint répondent au comportement attendu de l’annuaire. Pour Drupal, évaluez les fiches de services structurées, les relations et la navigation. Dans les deux propositions, identifiez le travail nécessaire pour le filtrage et le traitement des demandes.

Identifiez quels composants existants répondent à l’exigence et quelles interactions, relations ou règles de validation demandent un travail supplémentaire. Incluez les produits Drupal prêts à l’emploi dans cette évaluation au lieu de supposer que Drupal implique toujours de partir d’un framework vide.

Comparez aussi l’expérience des éditeurs

Demandez aux équipes de communication interne et RH de réaliser les mêmes tâches dans chaque mise en œuvre proposée :

Créer une actualité avec une image et une date de publication.
Mettre à jour une politique sans modifier accidentellement sa mise en page.
Soumettre la modification pour validation.
Identifier le responsable et la prochaine date de révision.
Archiver un contenu obsolète sans casser les liens essentiels.

SharePoint propose des contrôles de publication pour les pages et les bibliothèques ; des processus de validation plus élaborés peuvent faire appel à Power Automate ou à d’autres services. Drupal prend en charge les contenus structurés et des workflows de modération configurables ; l’équipe doit néanmoins configurer et tester l’expérience éditoriale souhaitée.

Le comportement responsive et l’accessibilité doivent figurer dans les critères d’acceptation, et non dans les hypothèses. Testez la navigation au clavier, le comportement avec un lecteur d’écran, les mises en page mobiles et les applications intégrées dans les deux mises en œuvre.

Enfin, demandez ce qui se passe après le lancement. Une personnalisation poussée signifie davantage de tests de régression, plus de travail lors des mises à niveau et une plus grande dépendance à des compétences spécialisées, quelle que soit la plateforme.

Que coûte chaque intranet au-delà des licences ?

La bonne comparaison porte sur le coût du lancement, de l’exploitation et des évolutions futures de l’intranet, et pas seulement sur la ligne des licences logicielles.

L’accès à SharePoint est inclus dans certains abonnements Microsoft 365 et disponible via des abonnements autonomes adaptés. Les achats doivent vérifier les conditions actuelles, la couverture des collaborateurs et les fonctionnalités requises. Ne supposez pas que chaque collaborateur de terrain, prestataire ou utilisateur externe dispose de l’accès nécessaire.

Notez ce que couvrent les abonnements existants et ce qui reste un coût supplémentaire. L’architecture de l’information, la migration, la configuration, la formation et la gouvernance doivent tout de même être budgétées.

Drupal core n’implique aucun frais de licence logicielle. L’hébergement, le développement, les mises à jour, la surveillance de la sécurité et le support nécessitent néanmoins un budget. Des extensions commerciales ou des services connectés peuvent ajouter des frais récurrents.

Utilisez la même grille de coûts pour les deux plateformes

Catégorie de coût	Ce qu’il faut inclure
Discovery et design	Recherche auprès des collaborateurs, audit de contenu, navigation, taxonomie, accessibilité et prototypes
Mise en œuvre	Configuration, modèles de pages, modèles de contenu, workflows et composants sur mesure
Intégrations	Identité, données RH, systèmes documentaires, API et tests d’accès
Migration	Nettoyage des contenus, mapping, transfert, redirections et validation
Recherche	Configuration de la recherche, indexation, connecteurs et éventuelle infrastructure de recherche supplémentaire
Licences et modules complémentaires	Abonnements requis, extensions payantes, connecteurs premium et stockage supplémentaire le cas échéant
Hébergement et exploitation	Infrastructure Drupal ou besoins de service supplémentaires, monitoring, sauvegardes et dispositifs de restauration
Adoption	Formation des éditeurs, guides pour les collaborateurs, communication de lancement et support du pilote
Support continu	Administration, correctifs le cas échéant, maintenance des extensions, gestion des incidents et améliorations
Sortie	Exports, workflows de remplacement, adaptation des intégrations et migration vers une autre plateforme

Construisez un modèle pluriannuel avec le même nombre de collaborateurs, les mêmes fonctionnalités, les mêmes heures de support et les mêmes hypothèses de ressources internes. Séparez les coûts ponctuels des dépenses récurrentes.

Pour SharePoint, distinguez les dépenses Microsoft 365 existantes de l’organisation des nouveaux coûts imputables à l’intranet. Pour Drupal, déterminez si l’hébergement et le support sont facturés séparément ou inclus dans un contrat de service.

Chiffrez aussi les demandes d’évolution probables : ajouter un pays, changer de système RH, introduire une nouvelle langue ou réorganiser des départements. Elles révèlent souvent des écarts de coûts qu’une estimation limitée au lancement ne montre pas.

Les coûts de sortie méritent également attention. L’accès au code source de Drupal peut faciliter la portabilité, mais des modules sur mesure, des dépendances d’infrastructure et un travail non documenté peuvent tout de même rendre un changement coûteux. Les contenus SharePoint peuvent être exportables, tandis que les workflows et extensions propres à la plateforme devront peut-être être reconstruits ailleurs.

Qui contrôle l’accès, la gouvernance et l’hébergement ?

Une plateforme ne remplace pas une répartition claire des responsabilités. Avant la mise en œuvre, désignez un product owner de l’intranet et des responsables de contenu, et convenez de qui approuve les règles d’accès, les changements de publication et les décisions de conservation.

L’IT, les RH, la communication interne, le service juridique et les représentants des métiers doivent prendre ces décisions ensemble.

Séparez personnalisation et protection

L’accès dans SharePoint repose généralement sur les sites, les groupes, l’héritage des permissions et les contrôles de partage. Rompre l’héritage pour des éléments individuels permet de gérer des exceptions, mais des exceptions nombreuses deviennent difficiles à contrôler.

Drupal fournit des rôles et des permissions. Des exigences comme des contenus réservés à un département, un accès au niveau de chaque enregistrement ou des restrictions par site peuvent nécessiter des modules supplémentaires ou une logique d’accès sur mesure.

Le ciblage d’audience n’est pas un contrôle d’accès. Masquer un lien ou personnaliser une page d’accueil ne prouve pas que la page ou le fichier sous-jacent est protégé.

Testez l’accès via des URL directes, les résultats de recherche, les API et les téléchargements, et pas seulement via la navigation. Incluez des utilisateurs sans accès, avec un accès partiel et avec plusieurs rôles dans l’organisation.

Définissez le cycle de vie des contenus

Les deux voies nécessitent des règles explicites pour :

Qui est responsable de chaque espace de contenu.
Quelles modifications nécessitent une validation.
Quand les contenus doivent être révisés.
Ce qui se passe lorsqu’un responsable quitte l’organisation.
Quand les contenus sont archivés ou supprimés.
Comment traiter les documents soumis à des obligations de conservation.

Certaines exigences peuvent s’appuyer sur les capacités natives de la plateforme. D’autres nécessitent de la configuration, de l’automatisation, des extensions ou des services supplémentaires. Un champ de date de révision, par exemple, ne crée pas à lui seul un processus de rappel et d’escalade.

Attribuez la responsabilité opérationnelle

Avec SharePoint Online, Microsoft exploite le service sous-jacent. Votre organisation reste responsable des identités, des accès, de la configuration du partage, des contenus et des extensions qu’elle gère. Les attentes en matière de restauration et les dispositifs de conservation doivent tout de même être validés.

Avec Drupal, l’organisation ou son prestataire doit prendre en charge :

L’hébergement et la configuration des environnements.
Les mises à jour de Drupal, des modules et des dépendances.
Les sauvegardes et des restaurations testées.
Le monitoring et la réponse aux incidents.
L’évaluation et la correction des vulnérabilités.
Le déploiement et les tests de régression.

Inscrivez ces responsabilités dans le contrat ou dans un accord d’exploitation interne. « Support inclus » ne suffit pas sans délais de réponse, périmètre de couverture et circuits d’escalade définis.

La résidence des données, la conservation, les pistes d’audit et la conformité doivent être évaluées par rapport à l’abonnement SharePoint réellement utilisé ou à l’architecture du déploiement Drupal. Incluez les sauvegardes, les journaux, les outils d’analyse et les systèmes connectés dans cet examen.

Drupal offre le contrôle du code source et de l’hébergement. Cela peut aider à satisfaire des exigences spécifiques, mais l’open source ne rend pas automatiquement un déploiement sécurisé ou conforme.

Que vérifier selon les différents scénarios de travail ?

Utilisez les scénarios de travail pour identifier ce qui doit être démontré, et non pour désigner une plateforme gagnante avant les tests. Une même organisation peut combiner plusieurs des situations ci-dessous.

Les collaborateurs travaillent déjà dans Microsoft 365

Listez les tâches documentaires et collaboratives qui doivent rester connectées à Teams et aux applications Office. Faites démontrer ces parcours dans chaque intranet proposé, y compris la connexion, l’accès aux documents restreints et le retour au point de départ du collaborateur.

Éléments à demander : ce qui est inclus, ce qui doit être configuré, quelles extensions ou quels services interviennent et quelles licences sont nécessaires.

Les outils Microsoft existants font partie du contexte. Ils ne prouvent pas, à eux seuls, que l’intranet destiné aux collaborateurs répond à vos besoins.

Les contenus et les parcours des collaborateurs exigent des structures spécifiques

Une politique s’applique peut-être à plusieurs sites, un annuaire de services relie des données issues de plusieurs systèmes, ou les collaborateurs ont besoin de parcours différents à travers les mêmes informations.

Éléments à demander : un prototype de l’exigence la plus difficile sur chaque point de départ proposé, y compris ce que les éditeurs doivent faire pour le maintenir.

Comparez les limites des composants existants, les modifications nécessaires et la manière dont elles seront testées et maintenues. Distinguez la configuration d’un produit prêt à l’emploi du développement nouveau.

Les exigences d’hébergement et de localisation des données sont impératives

Formalisez les contraintes réelles avant de comparer les options de déploiement. Incluez les sauvegardes, les intégrations, les journaux et les accès du support, au lieu de vérifier uniquement l’application principale.

Éléments à demander : une évaluation documentée du service SharePoint Online ou du déploiement Drupal étudié au regard de chaque exigence, avec des responsabilités opérationnelles nommément attribuées.

Une exigence impérative non satisfaite est un écart à résoudre, pas une préférence que l’on peut diluer dans la moyenne d’une grille d’évaluation.

Le portail et le référentiel documentaire restent séparés

Une architecture à évaluer consiste en un portail collaborateurs basé sur Drupal, SharePoint étant conservé pour le stockage documentaire et la collaboration.

Éléments à demander : une correspondance des identités, un accès aux documents, un comportement de recherche et des règles de responsabilité qui fonctionnent dans les deux systèmes.

Tenez compte de l’effort nécessaire pour une recherche respectant les permissions et pour la synchronisation des changements d’accès. Évitez de copier les documents dans les deux systèmes sans exigence claire ; les collaborateurs doivent savoir où se trouve la version à jour.

La proposition s’appuie sur Open Intranet

Évaluez Open Intranet comme un produit existant basé sur Drupal, plutôt que comme un framework vide, et sans supposer que chaque exigence est déjà couverte.

Éléments à demander : quelles capacités requises sont présentes, lesquelles doivent être configurées et lesquelles nécessitent du développement ou un autre service.

Utilisez les mêmes tâches, les mêmes tests d’accès et les mêmes hypothèses de coûts que pour l’évaluation de SharePoint. La discussion reste ainsi ancrée dans ce qui serait réellement livré.

Comment valider le choix avant de vous engager ?

Une évaluation fondée sur les tâches révèle les écarts plus tôt que des présentations séparées des fournisseurs.

Commencez par répartir les exigences entre conditions impératives et préférences. Une exigence impérative non satisfaite en matière d’accès, d’hébergement ou d’accessibilité doit bloquer la sélection, et non disparaître dans une note moyenne.

Mettez-vous ensuite d’accord sur les pondérations avant de noter les plateformes :

Critère	Éléments à demander
Adéquation avec Microsoft 365	Démonstration des tâches liées à l’identité, aux documents et à Teams
Réalisation des tâches des collaborateurs	Utilisateurs pilotes qui trouvent l’information et accèdent aux services
Personnalisation	Un prototype de la structure de contenu ou de l’interface requise la plus difficile
Permissions	Tests d’accès positifs et négatifs avec des rôles réalistes
Hébergement et conformité	Une évaluation documentée du service ou du déploiement
Coût pluriannuel	Hypothèses, exclusions, ressources et frais récurrents comparables
Exploitabilité	Responsabilités nommément attribuées, conditions de support et approche de maintenance

Donnez aux deux équipes de mise en œuvre le même scénario de démonstration :

Publier une actualité validée. Une éditrice soumet un brouillon, un valideur l’examine et un collaborateur voit le résultat publié.
Consulter une politique restreinte. Un collaborateur autorisé l’ouvre, tandis qu’un collaborateur non autorisé ne peut y accéder ni par la navigation, ni par la recherche, ni par un lien direct.
Trouver un document à travers les systèmes connectés. Le collaborateur trouve la version à jour et l’ouvre avec les bonnes permissions.

Utilisez des comptes réalistes plutôt que des accès administrateur. Incluez une collaboratrice de terrain, un éditeur régional et un utilisateur à accès restreint.

Pour chaque tâche, demandez une ventilation indiquant ce qui est :

Inclus dans la plateforme ou le produit proposé.
Configuré pendant la mise en œuvre.
Développé sur mesure.
Fourni par un autre service.
Dépendant d’une licence supplémentaire.

Exigez des responsables nommés pour le support et la maintenance, et consignez les hypothèses qui restent à valider. Pendant un pilote, mesurez la réalisation des tâches, le succès des recherches et l’effort des éditeurs plutôt que de vous fier uniquement aux pages vues.

Terminez par un bilan des résultats démontrés, des écarts restants, des coûts pluriannuels et des responsabilités opérationnelles. Indiquez aussi comment chaque proposition gère les évolutions futures probables. C’est une base de décision plus solide que de supposer qu’un abonnement existant règle la question ou que davantage de personnalisation est automatiquement bénéfique.

Prêt à vous lancer ?

Si Drupal figure sur votre shortlist, évaluez Open Intranet avec les mêmes tâches des collaborateurs, les mêmes tests d’accès et les mêmes hypothèses de coûts que pour SharePoint.

Demandez une présentation d’Open Intranet centrée sur vos exigences. Venez avec vos tâches prioritaires et vos contraintes les plus difficiles, et demandez à l’équipe de distinguer les capacités existantes de la configuration et du développement qu’il faudrait encore chiffrer.