Build vs Buy vs Open Source : choisir votre plateforme intranet

The right intranet can reduce time spent searching for policies, connect employees to services, and make internal communication easier to act on. But intranet platform selection also determines which costs, constraints, and maintenance responsibilities your organization will carry for years.

Custom development, commercial products, and Open Source platforms each distribute those responsibilities differently. The decision is not simply whether to pay for software or developers. It is whether the platform fits your essential workflows, connects to your systems, and remains affordable to operate and change.

Use this framework to compare five-year cost, integration fit, control, and exit options before feature lists dominate the conversation.

Dans cet article :

What are you actually choosing when you build, buy, or adopt Open Source?
Which constraints should rule a platform in or out?
When does each approach make business sense?
How much control do integrations and security requirements demand?
What will the intranet cost over five years?
Where can lock-in appear, and how can you test your exit options?
Where do Drupal and Open Intranet fit?
How do you turn the trade-offs into a defensible decision?

What are you actually choosing when you build, buy, or adopt Open Source?

The most useful distinction is how much existing behavior you can adopt and how much engineering responsibility you will retain.

Custom build means developing an intranet around organization-specific requirements. You control its behavior, but you must fund ongoing engineering, testing, security updates, and documentation. Building does not require writing every component from scratch.

Buying means adopting an existing commercial intranet product within its supported configuration and extension boundaries. The vendor maintains the product, while your team still owns responsibilities such as content governance, access decisions, configuration, and adoption.

Adopting Open Source means using an existing codebase that you can inspect and modify under its license. Your organization can maintain it internally, contract a provider, or combine both approaches.

These categories overlap. A custom intranet can use Drupal, and an Open Source intranet can come with paid implementation, hosting, and support. A commercial product may also require substantial integration work.

Separate three decisions:

The starting platform: An existing intranet product, a content platform, or a custom application.
The delivery and maintenance model: Internal staff, an external provider, or shared ownership.
The hosting model: Vendor-hosted software, managed hosting, or infrastructure your organization controls.

Evaluating these separately prevents assumptions such as “Open Source means self-hosted” or “buying means no internal work.”

Which constraints should rule a platform in or out?

Start with business outcomes rather than a catalog of features. A short list might include:

Help employees find the current policy without asking HR.
Provide one entry point for common employee services.
Reach frontline staff who rarely use a desktop.
Make departmental publishing accountable and consistent.

Define how you will measure those outcomes. Policy findability might be tested through task completion and time spent searching. Employee-service access might be assessed through successful task completion rather than page views.

Next, identify the constraints that can eliminate a candidate:

Constraint	Question to resolve before shortlisting
Launch deadline	Can essential workflows launch within the available time?
Budget	Can you fund implementation and continued operation?
Operating capacity	Who will maintain integrations, access rules, and software?
Identity and access	Can the platform meet sign-in, provisioning, and access-removal requirements?
Data residency	Can required data, backups, and logs remain in approved locations?
Accessibility	Can the configured employee experience meet your required standard?
Enterprise connections	Can essential systems exchange the required data reliably?

Treat mandatory requirements as pass-or-fail gates. A platform that cannot meet a legal or security requirement should not win because it scores highly on visual design.

Also separate standard needs from distinctive behavior. Publishing news is common. Routing employee requests through several legacy systems with different authorization rules may require deeper development.

Have IT, HR, Internal Comms, security or Legal, and employee representatives validate these gates. This keeps one department’s preferences from becoming an organization-wide constraint.

When does each approach make business sense?

Favor custom development when distinctive workflows justify the engineering cost. The case is strongest when standard product behavior would force costly workarounds and your organization can sustain a product owner, development capacity, and ongoing maintenance.

Favor a commercial product when its existing behavior closely matches employee needs. This can reduce initial delivery work, especially when supported connectors cover essential integrations. The trade-off is accepting product boundaries and the vendor’s roadmap.

Favor Open Source when code access, hosting choice, and extension freedom have clear business value. It offers an adaptable foundation, but that freedom needs an explicit maintenance plan.

Dimension	Custom build	Commercial intranet product	Open Source platform
Launch effort	More behavior must be designed and tested	Lower when configuration and supported connectors are sufficient	Depends on the starting point and required extensions
Customization boundaries	Broad, subject to engineering capacity	Defined by product settings and extension interfaces	Broad within the platform architecture and license
Integration options	Can be built where interfaces and access permit	Supported connectors and APIs, sometimes restricted by plan	Existing modules and APIs, plus custom development
Operating responsibility	Primarily your organization and its providers	Vendor owns product maintenance; customer retains configuration and governance duties	Your organization and contracted providers divide responsibilities
Main cost drivers	Engineering, staffing, testing, and ongoing change	Subscriptions, implementation, connectors, and service tiers	Implementation, hosting, support, integrations, and upgrades
Exit flexibility	Depends on ownership, documentation, and architecture	Depends on export capabilities and contract terms	Code access helps, but data portability and handover still need testing

Consider an organization that mainly needs news, policies, a directory, and links to employee services. If a commercial product meets its identity and accessibility requirements with little modification, buying may avoid unnecessary development.

Now consider an organization connecting several legacy systems through organization-specific access rules. A Drupal-based implementation or another custom approach may offer more control over those interactions.

Neither scenario makes one category universally cheaper. The cost advantage depends on how closely the starting point matches the work employees need to do.

How much control do integrations and security requirements demand?

Control matters most where platform limitations create recurring work, risk, or dependency.

Distinguish three levels of change:

Configuration: Supported settings, content structures, permissions, and layouts. Usually the easiest changes to maintain.
Supported extensions: Modules, plugins, APIs, or documented extension points. These require compatibility testing and clear ownership.
Changes to core behavior: Modifications outside supported extension boundaries. These can make upgrades harder and increase dependence on the original developers.

For Drupal, prefer configuration and supported extension mechanisms over editing core code. Code access makes modification possible; it does not make every modification economical.

Test identity beyond successful sign-in. SSO alone does not prove that the employee lifecycle is covered. Check provisioning, group changes, contractor access, and what happens when someone leaves. Establish how quickly access must end and how active sessions are handled.

For HRIS, Microsoft 365, Google Workspace, ticketing, and document systems, ask:

Which records and actions must move between systems?
Is the connection one-way or two-way?
Are connectors and API access included in the quoted plan?
What rate limits, synchronization delays, or storage limits apply?
How do permissions map between systems?
Who repairs the integration when an upstream API changes?

Search deserves particular attention. A connected search experience must not expose restricted content through titles, snippets, or cached results.

For security and operations, request evidence of:

Hosting locations and the treatment of backups and logs.
Audit events, retention options, and administrator access controls.
Responsibility for patching each software layer.
Incident response, backup restoration, and recovery procedures.
Performance under expected usage, including peak employee traffic.

Evaluate the actual deployment and contract, not just the platform’s advertised capabilities. A security feature only helps if it is configured, monitored, and assigned to an owner.

What will the intranet cost over five years?

A five-year view makes recurring commitments and likely change costs visible.

Use one shared model:

Five-year total cost of ownership = initial costs + recurring costs for years one through five + expected change costs + expected exit costs.

Build each estimate against the same scope and service expectations.

Cost category	What to include
Initial costs	Initial licensing where applicable, implementation, design, integrations, migration, security review, and launch enablement
Recurring costs	Subscriptions, hosting, support, internal staffing, maintenance, testing, monitoring, and routine upgrades
Expected changes	Employee growth, new integrations, additional workflows, storage growth, and major upgrade work
Exit costs	Data extraction, code and infrastructure handover, migration support, transition staffing, and contract termination costs where applicable

The distinction between routine maintenance and major change matters. If routine updates are included in support, do not count them again as separate development. If a major version upgrade requires separate funding, make that explicit.

Similarly, a subscription may include hosting and product updates but exclude connector support or configuration changes. Unpack the quote before comparing it with a managed Open Source service.

Internal time belongs in every estimate. Buying software does not remove the need for a product owner, content owners, access administration, and integration oversight. Custom development and Open Source may also require retained engineering capacity.

Prepare two scenarios using vendor quotes and internal estimates:

Base scenario: Expected employee count, agreed launch scope, planned integrations, and normal content growth.
Higher-cost scenario: Faster growth, additional connections, larger storage needs, more demanding service expectations, or substantial upgrade work.

Record assumptions about renewal pricing, currency, contract terms, and staffing availability. Include a contingency tied to identified uncertainties rather than an unexplained allowance.

Keep benefits visible alongside costs. For example, compare whether each candidate can reduce the steps required to find an approved policy. The lowest five-year price is not a saving if employees still need a manual workaround.

Where can lock-in appear, and how can you test your exit options?

Lock-in is the cost and difficulty of changing direction. It can appear in any approach.

Product lock-in: Proprietary content structures, limited exports, restricted APIs, or product-specific workflows.
Provider dependency: Only the implementation partner understands the customizations or can deploy changes.
Infrastructure dependency: Hosting-specific services or hard-coded assumptions make relocation difficult.
Internal specialist dependency: Critical knowledge sits with one employee and is not documented.

Open Source reduces some restrictions on code access, but it does not remove these operational dependencies.

Test portability before signing. Ask for a representative export containing content, files, metadata, relationships, and permissions. Check whether configuration can also be exported or documented sufficiently for reconstruction.

Then inspect usability. An export may contain every page while losing the taxonomy, links, or access rules needed to make those pages useful elsewhere.

For custom code, confirm contractual rights and access to:

Source repositories and relevant license information.
Deployment instructions and infrastructure configuration.
Technical documentation and integration specifications.
Test assets and operational runbooks.
Customer-controlled accounts needed to operate the service.

Ask one practical question: Could another capable team run and extend this system without rebuilding it?

A credible answer should include the likely handover effort, known dependencies, and any components that would need replacement. “You own your data” is not enough.

Where do Drupal and Open Intranet fit?

Drupal is an Open Source foundation for content-driven applications. Its content modeling, permissions, publishing workflows, and extension mechanisms can support an intranet, but Drupal alone is not a finished employee portal.

An implementation still needs intranet-specific configuration, user experience design, integrations, content preparation, testing, and maintenance. The amount of work depends on the required employee experience.

Open Intranet is a Drupal-based intranet system built by Droptica. It provides an existing starting point rather than requiring a team to begin with Drupal alone.

Within the Open Source path, the decision becomes:

Start with an existing intranet system when its available behavior aligns with your requirements.
Assemble a more organization-specific Drupal implementation when distinctive needs justify additional design and development.

An existing starting point can reduce work where it already matches your needs. Validate that fit rather than assuming every required workflow or connector is included.

Assess Open Intranet against the same tests as every other candidate:

Can it support your essential employee tasks?
Which integrations are available, and which require development?
Who owns hosting, patching, access controls, and incident response?
What does operation and change cost over five years?
Can another provider take over the implementation and its data?

Another route may be more suitable if a commercial product already meets your essential needs with less implementation work. Likewise, Open Source is not a sustainable choice if your organization cannot establish internal or contracted maintenance capacity.

How do you turn the trade-offs into a defensible decision?

A defensible decision connects platform capabilities to business priorities and makes uncertainty visible.

First, apply mandatory constraints. Remove candidates that fail essential security, residency, identity, accessibility, or integration requirements. Do not let optional features compensate for a failed gate.

Second, weight the remaining criteria. Compare five-year cost, launch effort, integration fit, control, maintainability, and exit readiness. Set weights according to your priorities, not a universal template.

An urgent launch may put more weight on existing functionality. A complex application landscape may make integration control more important. A small operating team may prioritize a clear managed-service arrangement.

Third, validate uncertain assumptions. Use a focused proof of fit:

Run a representative employee workflow, including permission checks.
Test a critical integration, including failure handling.
Export sample content and inspect what survives.
Document responsibility for patching, backups, upgrades, and support escalation.

Use a consistent scoring scale and record the evidence behind each score. A demonstrated workflow deserves more confidence than a roadmap promise. Keep scores and confidence levels separate so that uncertainty does not disappear inside a total.

Finally, write a short decision record. Include the preferred approach, reasons for rejecting alternatives, accepted trade-offs, five-year cost assumptions, named operating owners, and conditions that would trigger reconsideration.

For example, a commercial product may remain preferable only while its subscription includes a required connector. An Open Source implementation may depend on retaining a managed support contract. Record those dependencies before approval.

The rule is straightforward: buy for strong existing fit, build for justified distinctive needs, and adopt Open Source for an adaptable foundation with an explicit ownership plan.

Prêt à commencer ?

If Open Source is on your shortlist, review Open Intranet against your essential workflows, integration requirements, and five-year cost assumptions.

Bring your mandatory constraints and one representative employee journey to a platform-fit discussion with the Open Intranet team. The goal is to identify what fits today, what needs additional work, and whether this approach makes sense for your organization.