Build vs Buy vs Open Source : choisir votre plateforme intranet

Un bon intranet peut réduire le temps passé à chercher les politiques internes, donner aux collaborateurs un accès direct aux services et rendre la communication interne plus facile à mettre en pratique. Mais le choix de la plateforme intranet détermine aussi les coûts, les contraintes et les responsabilités de maintenance que votre organisation portera pendant des années.

Le développement sur mesure, les produits commerciaux et les plateformes Open Source répartissent chacun ces responsabilités différemment. La question n’est pas simplement de savoir s’il faut payer un logiciel ou des développeurs. Il s’agit de savoir si la plateforme couvre vos processus essentiels, se connecte à vos systèmes et reste abordable à exploiter et à faire évoluer.

Utilisez ce cadre pour comparer le coût sur cinq ans, l’adéquation des intégrations, le niveau de contrôle et les options de sortie avant que les listes de fonctionnalités ne monopolisent la discussion.

Dans cet article :

Que choisissez-vous réellement avec le build, le buy ou l’Open Source ?
Quelles contraintes doivent retenir ou exclure une plateforme ?
Quand chaque approche est-elle pertinente pour l’entreprise ?
Quel niveau de contrôle exigent les intégrations et la sécurité ?
Combien coûtera l’intranet sur cinq ans ?
Où la dépendance peut-elle apparaître, et comment tester vos options de sortie ?
Quelle place pour Drupal et Open Intranet ?
Comment transformer les arbitrages en une décision défendable ?

Que choisissez-vous réellement avec le build, le buy ou l’Open Source ?

La distinction la plus utile porte sur la part de fonctionnement existant que vous pouvez reprendre et sur la part de responsabilité technique que vous conserverez.

Le développement sur mesure (build) consiste à concevoir un intranet autour d’exigences propres à l’organisation. Vous maîtrisez son fonctionnement, mais vous devez financer en continu le développement, les tests, les mises à jour de sécurité et la documentation. Construire n’implique pas d’écrire chaque composant à partir de zéro.

L’achat (buy) consiste à adopter un produit intranet commercial existant, dans les limites de configuration et d’extension prises en charge. L’éditeur maintient le produit, tandis que votre équipe reste responsable de la gouvernance des contenus, des décisions d’accès, de la configuration et de l’adoption.

L’adoption de l’Open Source consiste à utiliser une base de code existante que vous pouvez examiner et modifier dans le cadre de sa licence. Votre organisation peut la maintenir en interne, faire appel à un prestataire ou combiner les deux approches.

Ces catégories se recoupent. Un intranet sur mesure peut reposer sur Drupal, et un intranet Open Source peut s’accompagner d’une implémentation, d’un hébergement et d’un support payants. Un produit commercial peut aussi nécessiter un travail d’intégration conséquent.

Distinguez trois décisions :

La plateforme de départ : un produit intranet existant, une plateforme de contenu ou une application sur mesure.
Le modèle de réalisation et de maintenance : équipes internes, prestataire externe ou responsabilité partagée.
Le modèle d’hébergement : logiciel hébergé par l’éditeur, hébergement infogéré ou infrastructure contrôlée par votre organisation.

Évaluer ces décisions séparément évite des présupposés comme « Open Source signifie auto-hébergé » ou « acheter signifie aucun travail en interne ».

Quelles contraintes doivent retenir ou exclure une plateforme ?

Partez des résultats attendus pour l’entreprise plutôt que d’un catalogue de fonctionnalités. Une courte liste pourrait inclure :

Aider les collaborateurs à trouver la politique en vigueur sans solliciter les RH.
Offrir un point d’entrée unique vers les services courants aux collaborateurs.
Atteindre les équipes de terrain qui utilisent rarement un ordinateur.
Rendre la publication par les départements responsable et cohérente.

Définissez comment vous mesurerez ces résultats. La facilité à trouver une politique peut être testée via le taux de réalisation des tâches et le temps de recherche. L’accès aux services aux collaborateurs peut être évalué par la réussite des tâches plutôt que par le nombre de pages vues.

Identifiez ensuite les contraintes susceptibles d’éliminer un candidat :

Contrainte	Question à trancher avant la présélection
Date de lancement	Les processus essentiels peuvent-ils être lancés dans le délai disponible ?
Budget	Pouvez-vous financer l’implémentation et l’exploitation continue ?
Capacité d’exploitation	Qui maintiendra les intégrations, les règles d’accès et le logiciel ?
Identité et accès	La plateforme répond-elle aux exigences de connexion, de provisionnement et de retrait des accès ?
Localisation des données	Les données, sauvegardes et journaux requis peuvent-ils rester dans des emplacements approuvés ?
Accessibilité	L’expérience collaborateur configurée peut-elle atteindre le niveau d’exigence requis ?
Connexions aux systèmes de l’entreprise	Les systèmes essentiels peuvent-ils échanger les données nécessaires de manière fiable ?

Traitez les exigences obligatoires comme des critères éliminatoires. Une plateforme qui ne satisfait pas une exigence juridique ou de sécurité ne doit pas l’emporter parce qu’elle obtient une bonne note en design visuel.

Séparez également les besoins standards des fonctionnements spécifiques. Publier des actualités est courant. Acheminer les demandes des collaborateurs à travers plusieurs systèmes historiques dotés de règles d’autorisation différentes peut exiger un développement plus poussé.

Faites valider ces critères par l’IT, les RH, la communication interne, la sécurité ou le service juridique, ainsi que par des représentants des collaborateurs. Cela évite que les préférences d’un seul département deviennent une contrainte pour toute l’organisation.

Quand chaque approche est-elle pertinente pour l’entreprise ?

Privilégiez le développement sur mesure lorsque des processus spécifiques justifient le coût de développement. C’est le cas le plus solide lorsque le fonctionnement standard d’un produit imposerait des contournements coûteux et que votre organisation peut assurer durablement un product owner, une capacité de développement et une maintenance continue.

Privilégiez un produit commercial lorsque son fonctionnement existant correspond étroitement aux besoins des collaborateurs. Cela peut réduire le travail de mise en place initial, en particulier lorsque des connecteurs pris en charge couvrent les intégrations essentielles. La contrepartie consiste à accepter les limites du produit et la feuille de route de l’éditeur.

Privilégiez l’Open Source lorsque l’accès au code, le choix de l’hébergement et la liberté d’extension ont une valeur métier claire. Il offre une base adaptable, mais cette liberté nécessite un plan de maintenance explicite.

Dimension	Développement sur mesure	Produit intranet commercial	Plateforme Open Source
Effort de lancement	Davantage de fonctionnalités à concevoir et à tester	Plus faible lorsque la configuration et les connecteurs pris en charge suffisent	Dépend du point de départ et des extensions requises
Limites de personnalisation	Larges, selon la capacité de développement	Définies par les paramètres du produit et les interfaces d’extension	Larges, dans le cadre de l’architecture de la plateforme et de la licence
Options d’intégration	Réalisables là où les interfaces et les accès le permettent	Connecteurs et API pris en charge, parfois limités selon l’offre	Modules et API existants, complétés par du développement sur mesure
Responsabilité d’exploitation	Principalement votre organisation et ses prestataires	L’éditeur maintient le produit ; le client conserve la configuration et la gouvernance	Votre organisation et ses prestataires se répartissent les responsabilités
Principaux postes de coût	Développement, effectifs, tests et évolutions continues	Abonnements, implémentation, connecteurs et niveaux de service	Implémentation, hébergement, support, intégrations et mises à niveau
Flexibilité de sortie	Dépend de la propriété, de la documentation et de l’architecture	Dépend des capacités d’export et des conditions contractuelles	L’accès au code aide, mais la portabilité des données et la passation doivent tout de même être testées

Prenons une organisation qui a principalement besoin d’actualités, de politiques internes, d’un annuaire et de liens vers les services aux collaborateurs. Si un produit commercial répond à ses exigences d’identité et d’accessibilité avec peu de modifications, l’achat peut éviter un développement inutile.

Prenons maintenant une organisation qui connecte plusieurs systèmes historiques au moyen de règles d’accès qui lui sont propres. Une implémentation basée sur Drupal ou une autre approche sur mesure peut offrir davantage de contrôle sur ces interactions.

Aucun de ces scénarios ne rend une catégorie universellement moins chère. L’avantage de coût dépend de la proximité entre le point de départ et le travail que les collaborateurs doivent accomplir.

Quel niveau de contrôle exigent les intégrations et la sécurité ?

Le contrôle compte surtout là où les limites de la plateforme génèrent du travail récurrent, des risques ou une dépendance.

Distinguez trois niveaux de modification :

Configuration : paramètres pris en charge, structures de contenu, permissions et mises en page. Ce sont généralement les modifications les plus simples à maintenir.
Extensions prises en charge : modules, plugins, API ou points d’extension documentés. Elles nécessitent des tests de compatibilité et une responsabilité clairement attribuée.
Modifications du fonctionnement du cœur : changements effectués hors des limites d’extension prises en charge. Ils peuvent compliquer les mises à niveau et accroître la dépendance envers les développeurs d’origine.

Avec Drupal, privilégiez la configuration et les mécanismes d’extension pris en charge plutôt que la modification du code du cœur. L’accès au code rend la modification possible ; il ne rend pas chaque modification économiquement pertinente.

Testez l’identité au-delà d’une connexion réussie. Le SSO seul ne prouve pas que tout le cycle de vie du collaborateur est couvert. Vérifiez le provisionnement, les changements de groupe, les accès des prestataires et ce qui se passe lorsqu’une personne quitte l’organisation. Déterminez en combien de temps l’accès doit être coupé et comment les sessions actives sont gérées.

Pour le SIRH, Microsoft 365, Google Workspace, l’outil de ticketing et les systèmes documentaires, posez les questions suivantes :

Quels enregistrements et quelles actions doivent circuler entre les systèmes ?
La connexion est-elle unidirectionnelle ou bidirectionnelle ?
Les connecteurs et l’accès aux API sont-ils inclus dans l’offre chiffrée ?
Quelles limites de débit, quels délais de synchronisation ou quelles limites de stockage s’appliquent ?
Comment les permissions se correspondent-elles d’un système à l’autre ?
Qui répare l’intégration lorsqu’une API en amont change ?

La recherche mérite une attention particulière. Une recherche connectée ne doit pas exposer de contenus restreints à travers des titres, des extraits ou des résultats mis en cache.

Pour la sécurité et l’exploitation, demandez des preuves concernant :

Les lieux d’hébergement et le traitement des sauvegardes et des journaux.
Les événements d’audit, les options de conservation et les contrôles d’accès des administrateurs.
La responsabilité de l’application des correctifs pour chaque couche logicielle.
La réponse aux incidents, la restauration des sauvegardes et les procédures de reprise.
Les performances sous la charge prévue, y compris lors des pics de trafic des collaborateurs.

Évaluez le déploiement et le contrat réels, pas seulement les capacités annoncées de la plateforme. Une fonctionnalité de sécurité n’est utile que si elle est configurée, surveillée et confiée à un responsable.

Combien coûtera l’intranet sur cinq ans ?

Une vision à cinq ans rend visibles les engagements récurrents et les coûts probables des évolutions.

Utilisez un modèle commun :

Coût total de possession sur cinq ans = coûts initiaux + coûts récurrents des années un à cinq + coûts d’évolution prévus + coûts de sortie prévus.

Établissez chaque estimation sur le même périmètre et les mêmes attentes de service.

Catégorie de coût	Éléments à inclure
Coûts initiaux	Licences initiales le cas échéant, implémentation, design, intégrations, migration, revue de sécurité et accompagnement au lancement
Coûts récurrents	Abonnements, hébergement, support, effectifs internes, maintenance, tests, supervision et mises à niveau courantes
Évolutions prévues	Croissance des effectifs, nouvelles intégrations, processus supplémentaires, augmentation du stockage et mises à niveau majeures
Coûts de sortie	Extraction des données, passation du code et de l’infrastructure, accompagnement à la migration, effectifs de transition et frais de résiliation du contrat le cas échéant

La distinction entre maintenance courante et évolution majeure est importante. Si les mises à jour courantes sont incluses dans le support, ne les comptez pas une seconde fois comme du développement distinct. Si une mise à niveau de version majeure nécessite un financement séparé, indiquez-le explicitement.

De même, un abonnement peut inclure l’hébergement et les mises à jour du produit, mais exclure le support des connecteurs ou les modifications de configuration. Décortiquez le devis avant de le comparer à un service Open Source infogéré.

Le temps interne doit figurer dans chaque estimation. Acheter un logiciel ne supprime pas le besoin d’un product owner, de responsables de contenus, d’une administration des accès et d’un suivi des intégrations. Le développement sur mesure et l’Open Source peuvent aussi nécessiter de conserver une capacité de développement.

Préparez deux scénarios à partir des devis fournisseurs et des estimations internes :

Scénario de base : effectif prévu, périmètre de lancement convenu, intégrations planifiées et croissance normale des contenus.
Scénario à coût élevé : croissance plus rapide, connexions supplémentaires, besoins de stockage plus importants, attentes de service plus exigeantes ou mises à niveau conséquentes.

Consignez vos hypothèses sur les tarifs de renouvellement, la devise, les conditions contractuelles et la disponibilité des effectifs. Prévoyez une provision pour aléas liée à des incertitudes identifiées plutôt qu’une marge inexpliquée.

Gardez les bénéfices visibles à côté des coûts. Par exemple, comparez la capacité de chaque candidat à réduire le nombre d’étapes nécessaires pour trouver une politique approuvée. Le prix le plus bas sur cinq ans n’est pas une économie si les collaborateurs doivent encore recourir à un contournement manuel.

Où la dépendance peut-elle apparaître, et comment tester vos options de sortie ?

La dépendance (lock-in) correspond au coût et à la difficulté de changer de direction. Elle peut apparaître dans n’importe quelle approche.

Dépendance au produit : structures de contenu propriétaires, exports limités, API restreintes ou processus propres au produit.
Dépendance au prestataire : seul le partenaire d’implémentation comprend les personnalisations ou peut déployer des modifications.
Dépendance à l’infrastructure : des services propres à l’hébergeur ou des hypothèses codées en dur rendent le déménagement difficile.
Dépendance à un spécialiste interne : des connaissances critiques reposent sur un seul collaborateur et ne sont pas documentées.

L’Open Source réduit certaines restrictions d’accès au code, mais il ne supprime pas ces dépendances opérationnelles.

Testez la portabilité avant de signer. Demandez un export représentatif contenant les contenus, les fichiers, les métadonnées, les relations et les permissions. Vérifiez si la configuration peut également être exportée ou suffisamment documentée pour être reconstruite.

Examinez ensuite l’exploitabilité. Un export peut contenir toutes les pages tout en perdant la taxonomie, les liens ou les règles d’accès nécessaires pour que ces pages soient utiles ailleurs.

Pour le code sur mesure, confirmez vos droits contractuels et votre accès aux éléments suivants :

Les dépôts de code source et les informations de licence pertinentes.
Les instructions de déploiement et la configuration de l’infrastructure.
La documentation technique et les spécifications des intégrations.
Les ressources de test et les procédures d’exploitation.
Les comptes contrôlés par le client nécessaires pour exploiter le service.

Posez une question pratique : une autre équipe compétente pourrait-elle exploiter et faire évoluer ce système sans le reconstruire ?

Une réponse crédible doit inclure l’effort de passation probable, les dépendances connues et les composants qui devraient être remplacés. « Vous êtes propriétaire de vos données » ne suffit pas.

Quelle place pour Drupal et Open Intranet ?

Drupal est une base Open Source pour les applications centrées sur le contenu. Sa modélisation des contenus, ses permissions, ses processus de publication et ses mécanismes d’extension peuvent servir de socle à un intranet, mais Drupal seul n’est pas un portail collaborateur clé en main.

Une implémentation nécessite encore une configuration propre à l’intranet, un travail de conception de l’expérience utilisateur, des intégrations, la préparation des contenus, des tests et de la maintenance. L’ampleur du travail dépend de l’expérience collaborateur attendue.

Open Intranet est un système intranet basé sur Drupal, développé par Droptica. Il fournit un point de départ existant, au lieu d’obliger une équipe à partir de Drupal seul.

Dans la voie Open Source, la décision devient la suivante :

Partir d’un système intranet existant lorsque ses fonctionnalités disponibles correspondent à vos exigences.
Assembler une implémentation Drupal plus spécifique à votre organisation lorsque des besoins particuliers justifient un travail supplémentaire de conception et de développement.

Un point de départ existant peut réduire le travail là où il correspond déjà à vos besoins. Validez cette adéquation plutôt que de supposer que chaque processus ou connecteur requis est inclus.

Évaluez Open Intranet selon les mêmes tests que tous les autres candidats :

Peut-il prendre en charge les tâches essentielles de vos collaborateurs ?
Quelles intégrations sont disponibles, et lesquelles nécessitent du développement ?
Qui est responsable de l’hébergement, des correctifs, des contrôles d’accès et de la réponse aux incidents ?
Que coûtent l’exploitation et les évolutions sur cinq ans ?
Un autre prestataire peut-il reprendre l’implémentation et ses données ?

Une autre voie peut être plus adaptée si un produit commercial répond déjà à vos besoins essentiels avec moins de travail d’implémentation. De même, l’Open Source n’est pas un choix durable si votre organisation ne peut pas mettre en place une capacité de maintenance interne ou externalisée.

Comment transformer les arbitrages en une décision défendable ?

Une décision défendable relie les capacités de la plateforme aux priorités de l’entreprise et rend l’incertitude visible.

Commencez par appliquer les contraintes obligatoires. Écartez les candidats qui ne satisfont pas les exigences essentielles de sécurité, de localisation des données, d’identité, d’accessibilité ou d’intégration. Ne laissez pas des fonctionnalités optionnelles compenser un critère éliminatoire non rempli.

Ensuite, pondérez les critères restants. Comparez le coût sur cinq ans, l’effort de lancement, l’adéquation des intégrations, le contrôle, la maintenabilité et la préparation à la sortie. Fixez les pondérations selon vos priorités, et non selon un modèle universel.

Un lancement urgent peut donner plus de poids aux fonctionnalités existantes. Un paysage applicatif complexe peut rendre le contrôle des intégrations plus important. Une petite équipe d’exploitation peut privilégier un service infogéré clairement défini.

Puis validez les hypothèses incertaines. Réalisez une preuve d’adéquation ciblée :

Exécutez un processus collaborateur représentatif, y compris les vérifications de permissions.
Testez une intégration critique, y compris la gestion des erreurs.
Exportez un échantillon de contenus et examinez ce qui est conservé.
Documentez la responsabilité des correctifs, des sauvegardes, des mises à niveau et de l’escalade du support.

Utilisez une échelle de notation cohérente et consignez les éléments qui justifient chaque note. Un processus démontré mérite davantage de confiance qu’une promesse de feuille de route. Gardez les notes et les niveaux de confiance séparés afin que l’incertitude ne disparaisse pas dans un total.

Enfin, rédigez un court document de décision. Indiquez l’approche retenue, les raisons du rejet des alternatives, les compromis acceptés, les hypothèses de coût sur cinq ans, les responsables d’exploitation nommés et les conditions qui déclencheraient un réexamen.

Par exemple, un produit commercial peut rester préférable uniquement tant que son abonnement inclut un connecteur indispensable. Une implémentation Open Source peut dépendre du maintien d’un contrat de support infogéré. Consignez ces dépendances avant l’approbation.

La règle est simple : achetez lorsque l’existant correspond fortement à vos besoins, développez sur mesure pour des besoins spécifiques justifiés, et adoptez l’Open Source pour une base adaptable assortie d’un plan de responsabilité explicite.

Prêt à commencer ?

Si l’Open Source figure dans votre présélection, évaluez Open Intranet au regard de vos processus essentiels, de vos exigences d’intégration et de vos hypothèses de coût sur cinq ans.

Apportez vos contraintes obligatoires et un parcours collaborateur représentatif à un échange sur l’adéquation de la plateforme avec l’équipe Open Intranet. L’objectif est d’identifier ce qui convient dès aujourd’hui, ce qui nécessite un travail supplémentaire et si cette approche a du sens pour votre organisation.