Livraison de projet intranet : agile, waterfall et MVP
La mise en place d’un intranet est rarement un simple projet technique. Il faut décider du périmètre, des responsabilités, de la migration des contenus, des intégrations, des tests et du lancement. Le choix entre agile et waterfall compte donc, mais il ne doit pas remplacer la discussion sur les risques, les phases et la valeur minimale pour les employés.
Une bonne méthode de livraison permet de publier une première version utile sans prétendre que tout peut être prévu dès le départ. Dans de nombreux projets, une approche hybride fonctionne le mieux : des limites et exigences obligatoires au début, puis des itérations courtes autour de l’expérience des employés.
Dans cet article :
- Que choisissez-vous vraiment entre agile et waterfall ?
- Quelle approche correspond à vos contraintes ?
- Que doit contenir le MVP d’un intranet ?
- Comment organiser la livraison en phases ?
- Quels critères doivent bloquer le lancement ?
- Comment recueillir le feedback après le lancement ?
- Comment éviter l’élargissement incontrôlé du périmètre ?
- Par où commencer le plan de livraison ?
Que choisissez-vous vraiment entre agile et waterfall ?
Agile et waterfall décrivent une manière de travailler, mais pas automatiquement une stratégie de publication. Agile ne veut pas dire que chaque sprint doit partir en production. Waterfall ne veut pas dire que tout l’intranet doit être lancé le même jour avec toutes les fonctionnalités.
Dans un projet intranet, séparez trois décisions :
| Décision | Question | Exemple |
|---|---|---|
| Méthode de travail | Comment l’équipe planifie, construit et valide le travail ? | Sprints avec tests utilisateurs ou séquence formelle avec validations. |
| Stratégie de publication | Quand les fonctionnalités arrivent-elles aux employés ? | Un lancement global ou des phases par pays, département ou fonctionnalité. |
| Périmètre du MVP | Qu’est-ce qui doit être prêt pour que le premier groupe puisse travailler ? | Page d’accueil, actualités, bibliothèque de documents, recherche et rôles éditoriaux de base. |
Agile est utile lorsque vous ne savez pas encore comment les employés chercheront l’information, quels libellés ils comprendront ou quels parcours sont vraiment critiques. Les cycles courts aident à tester la navigation, la page d’accueil, les formulaires et le workflow de publication.
Waterfall peut convenir lorsque les exigences sont stables et que les validations doivent passer par sécurité, juridique, IT et achats dans un ordre précis. Même dans ce cas, des tests précoces avec des employés restent nécessaires : une spécification approuvée ne prouve pas que l’intranet sera facile à utiliser.
Quelle approche correspond à vos contraintes ?
Choisissez la méthode selon l’incertitude et la capacité de décision, pas selon l’étiquette préférée par les parties prenantes.
Avant de valider le plan, posez ces questions :
- Les exigences sont-elles stables ou encore des hypothèses sur le comportement des employés ?
- La date de lancement est-elle fixe et quel événement métier l’explique ?
- Des utilisateurs représentatifs peuvent-ils tester les versions intermédiaires ?
- Un product owner peut-il décider régulièrement des priorités et du périmètre ?
- Quelles validations doivent être séquentielles ?
- Quelles dépendances échappent à l’équipe, comme le SSO, les données RH, les droits d’intégration ou les environnements de test ?
Si beaucoup de réponses restent incertaines, commencez par une approche hybride. Fixez le budget, les contraintes de sécurité, les dépendances et les critères de publication. Construisez ensuite les tâches clés des employés dans des itérations courtes.
Avec une date fixe, décidez tôt ce qui peut être déplacé. Les workflows secondaires, la personnalisation avancée ou certaines collections de contenus peuvent attendre. La sécurité, l’accessibilité et le fonctionnement pour le premier groupe doivent rester des conditions de lancement.
Que doit contenir le MVP d’un intranet ?
Le MVP d’un intranet est la plus petite version utilisable qui aide un groupe d’employés défini à accomplir des tâches importantes et qui produit des preuves pour la version suivante. Ce n’est pas la liste de tout ce que l’organisation aimerait avoir un jour.
Un bon MVP précise :
- le premier public, par exemple un pays, un service ou le siège,
- les tâches que ce public doit accomplir dès le premier jour,
- les contenus et propriétaires de contenus nécessaires,
- les rôles éditoriaux minimaux et le processus de publication,
- l’authentification et les permissions de base,
- les critères d’acceptation et la manière de signaler les problèmes.
Une première version peut contenir les actualités, une bibliothèque de politiques, la recherche, les pages de départements et les informations RH essentielles. La personnalisation complète, les campagnes de communication complexes ou toutes les intégrations peuvent suivre plus tard.
L’essentiel est que les employés puissent réaliser un vrai travail. Si l’intranet paraît prêt mais n’a pas de contenus validés, de permissions fiables ou de support défini, le MVP n’est pas prêt.
Comment organiser la livraison en phases ?
Les phases doivent réduire le risque et produire du feedback utile. Ne découpez pas le projet uniquement par modules techniques si les employés ne peuvent pas encore utiliser le résultat.
Un découpage pratique peut être :
- Découverte et décisions de base. Définir les problèmes employés, le propriétaire de l’intranet, les exigences obligatoires et les dépendances.
- MVP et architecture de l’information. Construire la navigation, les premiers types de contenus, les rôles éditoriaux et la structure visuelle.
- Contenus et migration. Choisir les contenus du premier lancement, clarifier les propriétaires, supprimer les doublons et approuver les pages clés.
- Intégrations et accès. Configurer le SSO, les sources de données, les permissions et les tests de sécurité.
- Pilote. Donner l’intranet à un groupe limité, recueillir les problèmes et vérifier que les tâches sont faisables.
- Lancement et stabilisation. Lancer pour le groupe choisi ou toute l’organisation, surveiller le support et corriger les obstacles critiques.
- Versions suivantes. Ajouter des fonctionnalités à partir de preuves, pas seulement à partir d’une liste de souhaits.
Chaque phase doit avoir un responsable, un résultat attendu, des critères d’acceptation et une décision prévue si quelque chose n’est pas prêt.
Quels critères doivent bloquer le lancement ?
Les critères de publication sont nécessaires, car un intranet touche de nombreuses parties de l’organisation. Le lancement ne doit pas dépendre seulement d’un build réussi.
Avant le lancement, vérifiez au minimum :
- connexion et déconnexion pour des groupes représentatifs,
- rôles et permissions pour les contenus sensibles,
- recherche des documents les plus importants,
- accessibilité et usage mobile des pages clés,
- qualité et fraîcheur des contenus de départ,
- propriétaires de contenus et règles de publication,
- processus de support et responsabilités,
- sauvegarde, monitoring et plan de secours,
- personne habilitée à approuver le lancement ou le retour arrière.
Tous les problèmes ne doivent pas bloquer la publication. Une faute de frappe sur une page secondaire peut aller dans la liste de corrections. Une erreur de permission, l’absence de support ou l’impossibilité de trouver une information obligatoire doivent arrêter le lancement pour le groupe concerné.
Comment recueillir le feedback après le lancement ?
Après le lancement, ne demandez pas seulement si les employés aiment l’intranet. Demandez s’ils peuvent accomplir des tâches concrètes.
Combinez plusieurs sources :
- tickets de support et causes récurrentes,
- recherches sans résultat,
- clics dans les parcours importants,
- questions posées aux équipes éditoriales et RH,
- courts entretiens avec des employés,
- observations du pilote et des premières semaines en production.
Transformez les observations en petites décisions. Si les employés ne trouvent pas la politique de congés, le problème peut venir du nom, de la place dans le menu, de la recherche ou d’un contenu manquant. Chaque hypothèse appelle une correction différente.
Gardez une liste de travail unique pour les bugs, les besoins utilisateurs et les tâches techniques. Cela évite de développer de nouvelles fonctions au détriment de la stabilité ou de repousser la maintenance jusqu’à ce qu’elle bloque une publication.
Comment éviter l’élargissement incontrôlé du périmètre ?
Le scope creep commence souvent avec de bonnes intentions. Chaque département a un besoin important, et l’intranet semble être l’endroit idéal pour le résoudre. Sans règles, la première version devient trop large.
Trois questions aident :
- Cette fonction est-elle nécessaire au premier groupe pour les tâches de lancement ?
- Son absence bloque-t-elle le lancement ou réduit-elle seulement le confort ?
- Avons-nous un propriétaire, un processus et les données nécessaires pour maintenir cette fonction après le lancement ?
Reportez les fonctions de manière explicite. Notez la raison, la condition de retour et le responsable de la décision. C’est plus utile qu’un simple « plus tard », qui peut devenir une source de conflit.
Un MVP doit être petit, mais complet pour son objectif. Si vous retirez un élément du lancement, vérifiez que le périmètre restant offre toujours un parcours utilisable aux employés.
Par où commencer le plan de livraison ?
Commencez par le premier groupe d’utilisateurs et ses tâches essentielles. Nommez ensuite les exigences obligatoires, les dépendances externes, les responsables de décision et les critères de publication.
Choisissez seulement après la méthode de travail. Agile, waterfall ou hybride doivent soutenir le risque du projet, pas devenir un objectif en soi.
Si vous préparez une implémentation Open Intranet, discutez avec Droptica des limites du MVP, des dépendances et des critères de lancement. Commencez par définir à qui sert la première version, ce que ces employés doivent pouvoir faire et quelles preuves montreront que l’intranet est prêt.
