Checklist de projet intranet : du business case au lancement

Il y a beaucoup de choses à suivre lorsqu’on lance un intranet : qui s’occupe de la bibliothèque des politiques internes, comment fonctionne l’accès des collaborateurs, et qui assurera le support une fois que tout le monde commencera à l’utiliser. Cette checklist de projet intranet aide votre équipe à traiter ces questions avant qu’elles ne deviennent des surprises de dernière minute.

Utilisez-la pour planifier un déploiement d’Open Intranet, vérifier comment le produit répond aux besoins des collaborateurs, et voir ce qui est prêt et ce qui demande encore de l’attention. Partez des capacités et de la configuration existantes. N’ajoutez des intégrations ou des extensions que là où une exigence convenue reste sans réponse.

Dans cet article :

Comment utiliser cette checklist
1. Confirmer le problème métier et le mandat du projet
2. Comprendre les collaborateurs et leurs besoins d’accès
3. Mettre en place la gouvernance et la prise de décision
4. Approuver le budget et le périmètre de livraison
5. Valider Open Intranet par rapport aux exigences
6. Confirmer l’hébergement, les contrats et le contrôle opérationnel
7. Définir les exigences d’identité, d’accès et de confidentialité
8. Auditer le contenu et définir la gouvernance éditoriale
9. Valider la navigation, la recherche et les parcours clés
10. Configurer les fonctionnalités de la première version
11. Connecter et tester les systèmes requis
12. Préparer les environnements et les procédures de reprise
13. Migrer et approuver le contenu de lancement
14. Réaliser les tests d’acceptation et le pilote auprès des collaborateurs
15. Préparer les collaborateurs et autoriser le lancement
16. Exploiter, améliorer et retirer l’ancien intranet
Transformer la checklist en plan de mise en œuvre

Comment utiliser cette checklist de projet intranet

Copiez les points de contrôle dans votre outil de suivi de projet ou dans un tableur partagé. Chacune des 16 phases contient six points de contrôle, soit 96 points de contrôle au total.

Ces colonnes constituent un bon point de départ :

Point de contrôle	Responsable	Échéance	Statut	Document ou décision à l’appui
Action à réaliser	Personne responsable	Date convenue	Statut actuel	Approbation, résultat de test ou document

Utilisez cinq valeurs de statut : non commencé, en cours, bloqué, terminé ou non applicable.

Avant de cocher un point comme terminé, assurez-vous que la personne responsable peut montrer le résultat convenu. Si un point ne s’applique pas, notez pourquoi et qui l’a validé. Laissez les fonctionnalités optionnelles optionnelles : décidez lesquelles vous sont nécessaires, puis configurez et testez uniquement celles retenues.

Vous n’avez pas besoin de terminer chaque phase avant de commencer la suivante. L’audit du contenu, l’examen de l’hébergement et l’évaluation du produit peuvent avancer en parallèle lorsque leurs dépendances le permettent. Chaque phase se termine par un bref rappel de ce qu’il faut avoir sous la main.

Gardez de la place pour une décision finale de lancement. Même lorsque la planification se déroule comme prévu, votre équipe doit encore passer en revue les points bloquants, convenir des risques qu’elle peut accepter et décider qui peut autoriser un retour arrière.

1. Confirmer le problème métier et le mandat du projet

Commencez par vous mettre d’accord sur ce que l’intranet doit améliorer avant de passer à la configuration, à la migration ou au développement.

Documentez les problèmes des collaborateurs que l’intranet doit résoudre, avec des exemples recueillis dans l’organisation.
Convenez des problèmes qui relèvent de l’intranet et de ceux qui restent dans les systèmes métier existants.
Nommez un sponsor exécutif ayant l’autorité pour approuver le financement et arbitrer les désaccords entre équipes.
Désignez un responsable unique de l’intranet et confirmez le temps qu’il peut y consacrer avant et après le lancement.
Définissez des résultats mesurables, des mesures de référence et un responsable nommé pour chaque mesure.
Approuvez une note de cadrage couvrant le périmètre, les contraintes, les résultats attendus et la raison de la date de lancement visée.

Faites d’« un accès plus facile aux politiques internes » quelque chose que vous pouvez vérifier ensemble. Par exemple, demandez à des collaborateurs de différentes équipes de retrouver la politique de déplacements en vigueur et d’identifier qui l’a approuvée. Notez le temps nécessaire, où ils bloquent et s’ils trouvent la bonne version. Répétez le même test après le lancement. Le nombre de pages vues ne vous dira pas, à lui seul, si la tâche est devenue plus facile.

Il est également utile de distinguer la recherche d’information de la réalisation d’une transaction. L’intranet peut expliquer un processus de notes de frais et renvoyer vers le système financier sans remplacer ce système.

Utilisez le guide du business case intranet pour relier les problèmes des collaborateurs aux décisions de financement.

À avoir sous la main : une note de cadrage approuvée et un plan pour mesurer votre point de départ.

2. Comprendre les collaborateurs et leurs besoins d’accès

Assurez-vous que la première version fonctionne pour les personnes censées l’utiliser, pas seulement pour l’équipe projet.

Identifiez les groupes de collaborateurs par rôle, site, langue, rythme de travail et accès à un appareil de l’entreprise.
Échangez avec ou observez des collaborateurs de bureau, à distance, de terrain et d’autres groupes pertinents.
Classez par priorité les tâches que les collaborateurs doivent accomplir, comme trouver une politique, localiser un collègue ou soumettre une demande.
Recensez les obstacles liés aux appareils partagés, aux téléphones personnels, aux connexions instables ou à l’absence d’e-mail professionnel.
Documentez les besoins linguistiques et d’accessibilité et incluez les collaborateurs concernés dans les tests prévus.
Vérifiez les tâches proposées pour la première version avec des personnes issues des groupes censés les utiliser.

Rappelez-vous que tout le monde n’a pas d’ordinateur portable, de messagerie professionnelle ni les mêmes horaires de travail. Un collaborateur de terrain qui utilise un terminal partagé a des besoins de connexion, de confidentialité et de support différents de ceux d’une personne qui utilise un ordinateur de l’entreprise à domicile.

Pour chaque tâche importante, notez qui doit la réaliser, comment il accédera à l’intranet, à quoi ressemble un bon résultat et ce qui pourrait lui faire obstacle. Votre équipe dispose ainsi d’un point de départ concret pour configurer les accès, tester l’expérience et expliquer le nouvel intranet aux collaborateurs.

À avoir sous la main : une vue d’ensemble de vos groupes de collaborateurs et une liste priorisée des tâches qui comptent le plus pour eux.

3. Mettre en place la gouvernance et la prise de décision

Donnez à chacun un point de contact clair et convenez de qui prend quelles décisions, pour que le travail continue d’avancer.

Nommez des représentants de l’IT, de la communication interne, des RH et des métiers concernés par le déploiement.
Identifiez à quel moment la sécurité, la protection des données, les achats, le juridique et les représentants du personnel doivent intervenir.
Attribuez la responsabilité des décisions produit, de la livraison, du contenu, des intégrations, des tests et du support continu.
Convenez de qui approuve les exigences, les modifications budgétaires, la préparation au lancement et les exceptions.
Convenez de la fréquence des réunions, de l’endroit où consigner décisions et risques, et de la personne à solliciter lorsque le travail bloque.
Réservez du temps pour les responsables de contenu, les collaborateurs testeurs, les administrateurs et les autres contributeurs internes.

Allez un cran plus loin que le simple nom d’un service : choisissez, pour chaque chantier, une personne capable de prendre les décisions ou d’obtenir la bonne approbation.

Gardez des notes de décision courtes mais utiles : la question, les options envisagées, la décision, l’approbateur, la date et les exigences concernées. Convenez de qui peut aider à débloquer une décision, pour que l’équipe n’ait pas à relancer sans cesse de manière informelle.

À avoir sous la main : une liste claire des responsabilités, des décideurs et du temps que chaque contributeur peut consacrer.

4. Approuver le budget et le périmètre de livraison

Planifiez à la fois la mise en production de l’intranet et son entretien une fois que les collaborateurs commencent à l’utiliser.

Estimez les coûts initiaux d’installation, de configuration, d’intégrations, de migration, de formation et des éventuelles extensions convenues.
Estimez les coûts récurrents d’hébergement, de support, de mises à jour, de gestion du contenu et de services tiers.
Incluez le temps du personnel interne et une réserve pour imprévus, avec un processus d’approbation convenu pour son utilisation.
Définissez ce qui est inclus dans la première version, ce qui est reporté et ce qui est explicitement exclu.
Convenez de jalons avec dépendances, responsables et critères d’acceptation, plutôt que de simples dates.
Approuvez à la fois le budget de mise en œuvre et un budget de fonctionnement, avec des détenteurs de budget nommés.

Open Intranet est un système Open Source construit sur Drupal. Il n’y a pas de frais de licence logicielle par utilisateur, mais les coûts de fonctionnement ont tout de même besoin d’une place dans le budget. Prévoyez l’hébergement, la maintenance, le travail éditorial, le support et les éventuels services externes payants. Consultez les informations tarifaires d’Open Intranet en parallèle de vos estimations internes de charge.

Donnez à chaque jalon une signification claire. « Prêt pour le pilote » doit signifier que le contenu convenu, l’accès des collaborateurs et les scénarios de test sont prêts, pas simplement que la semaine prévue est arrivée.

À avoir sous la main : un plan de livraison financé et un budget pluriannuel, avec les hypothèses et les détenteurs de budget consignés.

5. Valider Open Intranet par rapport aux exigences

Avant de planifier de nouveaux développements, explorez ce que le produit peut déjà faire pour votre équipe.

Transformez chaque exigence indispensable en un scénario qui peut être démontré et testé.
Passez en revue ces scénarios dans une démo ou une installation d’évaluation d’Open Intranet, avec du contenu représentatif.
Classez chaque exigence comme disponible, configurable, dépendante d’un module ou d’une intégration supplémentaire, ou nécessitant une extension.
Vérifiez la disponibilité et le statut de publication des fonctionnalités proposées, au lieu de considérer des fonctionnalités expérimentales ou en préversion comme prêtes pour le lancement.
Pour chaque écart restant, décidez s’il faut modifier le processus, configurer une capacité existante, ajouter un composant pris en charge, étendre ou reporter.
Approuvez l’examen de ce qui convient et de ce qui manque, avec les coûts, les responsabilités de maintenance et les critères d’acceptation de chaque extension proposée.

Commencez par la documentation produit d’Open Intranet et essayez vos tâches les plus prioritaires dans la version que vous prévoyez de déployer. L’objectif est de confronter un produit configuré à vos besoins, pas de commander chaque fonctionnalité à partir de zéro.

Par exemple, remplacez « prend en charge les documents à accès restreint » par un scénario : un collaborateur autorisé peut trouver et ouvrir un document, tandis qu’un compte non autorisé ne peut y accéder ni via la recherche ni via un lien direct.

Utilisez la ressource sur le cahier des charges intranet pour structurer la comparaison. Notez la version testée, les hypothèses de configuration, les résultats et les décisions encore à prendre.

Prévoyez du temps pour configurer et tester les intégrations d’identité dans votre propre environnement. De même, l’auto-hébergement doit être examiné au regard de vos obligations de sécurité et réglementaires.

À avoir sous la main : une comparaison approuvée entre vos exigences et les capacités du produit, avec une décision pour chaque écart restant.

6. Confirmer l’hébergement, les contrats et le contrôle opérationnel

Assurez-vous que votre équipe sait comment l’intranet sera exploité, ce qui est inclus et qui contacter pour obtenir de l’aide.

Choisissez une approche d’hébergement fondée sur les exigences de l’organisation et attribuez la responsabilité de son exploitation.
Documentez les emplacements prévus des données applicatives, des sauvegardes, des journaux et des traitements externes concernés.
Passez en revue les livrables de mise en œuvre, les exclusions, les conditions d’acceptation, la couverture du support et les frais récurrents.
Confirmez l’accès de l’organisation aux dépôts de code, à la configuration, aux exports de données, aux comptes d’hébergement et aux identifiants d’administration.
Documentez les dépendances tierces payantes, les frais à l’usage, les conditions de renouvellement et les limites de service.
Convenez d’un processus de transfert et de changement de prestataire, incluant exports, documentation, identifiants et assistance à la transition.

Choisissez l’hébergement en fonction de vos besoins réels : localisation des données, personnes disponibles pour l’exploiter, objectifs de reprise, contrôles d’accès et couverture du support. Pensez à inclure les traitements externes d’e-mail, d’analytics ou de recherche que vous retenez, et pas seulement le serveur applicatif principal.

Une distinction mérite d’être gardée à l’esprit : les droits d’accès au logiciel et la propriété des droits d’auteur sont deux choses différentes. Les licences Open Source accordent des droits selon leurs conditions ; elles ne transfèrent pas la propriété exclusive de l’ensemble du code contribué par la communauté. Les contrats doivent préciser les droits et les modalités de transfert pour les travaux spécifiques au projet.

À avoir sous la main : un choix d’hébergement approuvé et des accords écrits couvrant les responsabilités et les services.

7. Définir les exigences d’identité, d’accès et de confidentialité

Assurez-vous que les collaborateurs peuvent accéder aux informations dont ils ont besoin, tout en réservant les informations sensibles aux bonnes personnes.

Approuvez une matrice d’accès couvrant les collaborateurs, les éditeurs, les administrateurs, les prestataires et les zones de contenu sensible.
Choisissez le fournisseur d’identité et le mode de connexion, et documentez le travail de configuration ou d’intégration nécessaire.
Définissez la création de comptes, les changements de rôle, la suppression de comptes et le traitement des sessions existantes lorsqu’un accès est révoqué.
Convenez avec le responsable sécurité des exigences d’authentification, de session, d’appareils partagés et d’accès administrateur d’urgence.
Identifiez les données personnelles et sensibles et obtenez des responsables concernés les décisions sur la collecte, la visibilité, la conservation et la suppression.
Convenez des exigences de journalisation de sécurité, de revue des accès, de réponse aux incidents et de traitement des demandes des collaborateurs relatives à leurs données.

Consultez la documentation d’administration des utilisateurs d’Open Intranet lorsque vous cartographiez les rôles et les options d’identité. Vérifiez l’approche retenue par rapport à votre fournisseur d’identité, à votre déploiement et à vos groupes de collaborateurs.

Incluez la suppression de comptes dans vos tests. Après avoir désactivé un compte dans le système d’identité connecté, vérifiez ce qui arrive à un collaborateur déjà connecté à l’intranet. Convenez de la rapidité avec laquelle cet accès doit prendre fin, puis testez-la.

Utilisez ces points de contrôle pour guider la discussion avec vos collègues de la sécurité, de la protection des données et du juridique. Ce sont eux qui doivent approuver les exigences de votre déploiement ; la checklist ne constitue ni un conseil juridique ni une garantie de conformité.

À avoir sous la main : un plan approuvé de qui peut accéder à quoi, accompagné des exigences de sécurité et de confidentialité convenues.

8. Auditer le contenu et définir la gouvernance éditoriale

Donnez au nouvel intranet un point de départ utile et bien organisé, avec quelqu’un qui veille sur chaque zone de contenu.

Inventoriez les pages, fichiers, sources de connaissances et référentiels existants, avec leurs responsables et leurs publics cibles.
Classez chaque ensemble de contenu : à migrer, à réécrire, à archiver, à supprimer sous réserve de l’approbation des règles de conservation, ou à conserver dans son système actuel.
Attribuez un responsable et une prochaine date de revue à chaque zone de contenu incluse au lancement.
Convenez des types de contenu, des métadonnées obligatoires, des conventions de nommage et des règles de versionnage des documents.
Documentez le processus de brouillon, relecture, approbation, publication, correction et retrait.
Approuvez les consignes éditoriales et des modèles accessibles pour les types de contenu nécessaires à la première version.

Vous n’avez pas besoin d’emporter tous vos anciens fichiers. Commencez par les contenus dont les collaborateurs ont besoin pour les tâches de la première version. Demandez aux responsables de contenu de résoudre les politiques contradictoires et les documents en double avant l’import.

Utilisez la documentation d’administration des documents pour comparer vos règles de publication avec la configuration disponible. Lorsque l’information reste dans un autre système, indiquez clairement comment les collaborateurs trouveront la version actuelle et approuvée.

À avoir sous la main : une liste de migration du contenu, des responsables nommés et des règles de publication convenues.

Aidez les collaborateurs à trouver des informations utiles sans devoir connaître l’organigramme par cœur.

Organisez la navigation proposée autour des tâches des collaborateurs et validez les libellés avec les utilisateurs visés.
Convenez des priorités de la page d’accueil et du contenu que les différents publics doivent voir en premier.
Définissez la taxonomie, les métadonnées, les filtres et les sources de contenu que la recherche doit inclure ou exclure.
Préparez des requêtes de recherche représentatives avec les résultats utiles attendus, ainsi que des exemples de résultats restreints qui doivent rester masqués.
Testez les parcours clés dans un site d’évaluation configuré avant de commander des modifications d’interface inutiles.
Consignez les critères d’acceptation mobile et accessibilité, et résolvez les problèmes de navigation identifiés lors des premiers tests.

Partez de l’interface existante et de la configuration de la navigation d’Open Intranet. Essayez d’abord ces options avec les collaborateurs, puis prototypez des comportements supplémentaires là où un besoin non résolu le justifie.

Utilisez les mots que les collaborateurs taperaient réellement, pas seulement les titres exacts des documents. Par exemple, vérifiez si « congés » mène bien aux consignes d’absence correspondantes. Vérifiez aussi que les informations restreintes n’apparaissent pas dans les titres de résultats, les extraits et autres aperçus pour les comptes non autorisés.

À avoir sous la main : une navigation testée et un ensemble de tâches et de recherches de collaborateurs, avec des résultats attendus clairs.

10. Configurer les fonctionnalités de la première version

Concentrez la première version sur ce dont les collaborateurs ont le plus besoin. D’autres fonctionnalités utiles pourront suivre plus tard.

Configurez l’identité visuelle, les mises en page de la page d’accueil, la navigation et les modèles de page réutilisables pour les publics convenus.
Configurez les capacités retenues d’actualités, de connaissances, de documents et d’annuaire des personnes, ainsi que leurs responsables de contenu.
Décidez si les événements, les formulaires, les interactions sociales, les accusés de lecture et les autres fonctionnalités optionnelles ont leur place dans la première version.
Configurez les workflows, notifications, ciblages d’audience et règles de modération retenus, et testez leurs destinataires.
Configurez les langues, les champs de profil et les paramètres de visibilité retenus à l’aide de comptes de collaborateurs représentatifs.
Examinez chaque modification de code proposée au regard des options de configuration disponibles et documentez les exceptions approuvées.

Appliquez ces points de contrôle aux capacités que vous avez retenues et vérifiées pour la version prévue. Certaines options peuvent nécessiter des composants ou des travaux supplémentaires.

Gardez une trace des fonctionnalités optionnelles que vous incluez et de celles que vous remettez à plus tard. Il est inutile de configurer et de tester une fonctionnalité que vous avez décidé de ne pas utiliser. Pour celles incluses, confirmez d’abord la disponibilité, les dépendances, les permissions et les critères d’acceptation.

Pour les notifications, vérifiez qui reçoit le message, quelles informations il révèle et où mènent ses liens. Pour les profils, connectez-vous en tant que collaborateur ordinaire pour vérifier la visibilité des champs, plutôt que de vous fier à la vue administrateur.

À avoir sous la main : un relevé de la configuration et des résultats de test pour les fonctionnalités de votre périmètre convenu.

11. Connecter et tester les systèmes requis

Vérifiez que les informations circulent de manière fiable entre vos systèmes et que quelqu’un est prêt à intervenir si cela s’arrête.

Listez chaque intégration critique pour le lancement, avec son responsable système, sa finalité et l’approche de mise en œuvre approuvée.
Convenez de la source de référence, des correspondances de champs, du sens de transfert et de la fréquence de mise à jour pour chaque flux de données.
Obtenez les identifiants et permissions nécessaires et documentez comment les secrets sont stockés et renouvelés.
Testez les transferts réussis et les échecs, y compris les doublons, les champs manquants, les données obsolètes et les services indisponibles.
Confirmez qui reçoit les alertes d’échec, qui résout les incidents et comment les mises à jour manquées sont récupérées.
Documentez la supervision, les coûts récurrents et la responsabilité des tests lors de futures évolutions des systèmes connectés.

Convenez du système à privilégier en cas de valeurs contradictoires. Si les données de service des collaborateurs proviennent d’un système RH, décidez si les modifications dans l’intranet sont bloquées, écrasées ou traitées via un processus d’exception convenu.

Utilisez des données d’exemple réalistes ou des données protégées de manière appropriée dans les environnements de test. Gardez les données réelles sensibles hors d’une installation de test, sauf si leur utilisation a été correctement examinée et protégée.

Si aucune intégration n’est nécessaire pour le lancement, consignez simplement cette décision et son approbation. Cela montre clairement que l’équipe a examiné la question au lieu de la négliger.

À avoir sous la main : une liste des intégrations et des résultats de test approuvés, ou les raisons convenues de les écarter.

12. Préparer les environnements et les procédures de reprise

Donnez à votre équipe un moyen reproductible de livrer des mises à jour et un plan testé pour rétablir l’intranet en cas de problème.

Mettez en place des environnements distincts pour la configuration/les tests et la production, avec des restrictions d’accès appropriées.
Documentez et répétez le processus de passage en production de la configuration et du code approuvés.
Configurez le domaine, les connexions chiffrées, les messages sortants, les tâches planifiées et l’infrastructure de recherche requis par le déploiement.
Mettez en place la supervision de la disponibilité, des erreurs, de la capacité, des tâches en arrière-plan et des intégrations critiques, avec des destinataires d’alertes nommés.
Convenez des objectifs de reprise et démontrez une restauration depuis une sauvegarde dans un environnement contrôlé.
Documentez les tests de mise à jour, les responsabilités en matière de correctifs de sécurité, l’escalade des incidents et les procédures de retour arrière des déploiements.

Convenez du niveau de perte de données et d’indisponibilité que l’organisation peut accepter. Utilisez ces objectifs pour décider de la fréquence des sauvegardes, de leur durée de conservation et de la manière de les restaurer.

Testez la restauration, pas seulement la sauvegarde. Restaurez la base de données, les fichiers et la configuration requis, puis vérifiez les accès et les tâches clés des collaborateurs. Notez le temps nécessaire et les étapes à réaliser manuellement.

Restreignez les messages sortants dans les environnements de test pour que les répétitions ne notifient pas accidentellement les collaborateurs. Séparez les instructions d’annulation d’un déploiement de celles de reprise complète du service.

À avoir sous la main : un guide d’exploitation pratique, un test de restauration réussi et des personnes nommées responsables de l’exploitation du service.

13. Migrer et approuver le contenu de lancement

Déplacez le contenu approuvé vers son nouvel emplacement et vérifiez que les collaborateurs trouveront la bonne version.

Faites correspondre le contenu source, les fichiers, les métadonnées, la propriété et les permissions à leurs structures de destination.
Réalisez une migration d’essai couvrant des types de contenu, des documents et des restrictions d’accès représentatifs.
Vérifiez le contenu migré : fichiers manquants, liens cassés, doublons, problèmes de mise en forme et permissions incorrectes.
Faites approuver par les responsables de contenu le contenu de lancement réécrit et migré, y compris les politiques clés et les pages d’aide.
Convenez du gel du contenu, du processus de mise à jour finale, des responsabilités de bascule et du plan de repli.
Définissez les redirections, l’accès aux archives et le plan de retrait des anciens emplacements de publication, pour que les collaborateurs sachent quelle version fait référence.

Comparez ce que vous prévoyiez de migrer avec ce qui est réellement arrivé. Notez ce qui a été migré, ce qui a échoué, ce qui a été délibérément écarté et ce qui nécessite une correction manuelle. Le comptage des enregistrements aide à repérer les éléments manquants, mais pensez aussi à vérifier les permissions, les liens et le contenu lui-même.

Votre plan de transition vers le lancement doit expliquer comment les modifications effectuées après la migration d’essai parviennent au site en production. Convenez de qui peut publier pendant le gel du contenu et de la manière de traiter les corrections urgentes.

À avoir sous la main : des résultats de migration vérifiés, l’approbation des responsables de contenu et un plan pour la bascule finale.

14. Réaliser les tests d’acceptation et le pilote auprès des collaborateurs

Invitez les collaborateurs à essayer l’intranet dans les conditions où ils l’utiliseront réellement, et confrontez les résultats à vos exigences convenues.

Démontrez que chaque exigence critique pour le lancement passe son test d’acceptation convenu.
Testez les permissions avec des comptes autorisés et non autorisés, y compris les liens directs vers les fichiers, les résultats de recherche et les notifications.
Testez la connexion, la suppression de comptes, l’usage mobile, les navigateurs pris en charge, la navigation au clavier et les technologies d’assistance pertinentes.
Testez les performances selon les scénarios d’utilisation convenus et consignez les résultats par rapport aux seuils acceptés.
Menez un pilote avec des collaborateurs représentatifs et consignez l’accomplissement des tâches, les retours et les demandes de support.
Corrigez les défauts bloquants pour le lancement et obtenez des décisions écrites, des responsables et des échéances pour les problèmes restants acceptés.

Essayez les tâches en tant que collaborateur ordinaire, pas seulement en tant qu’administrateur. Incluez différents rôles et conditions d’accès, comme des comptes restreints et des appareils partagés lorsque c’est pertinent.

Convenez des scénarios de performance avant de lancer les tests : activité simultanée attendue, pages les plus consultées, recherches et accès aux documents. Notez l’environnement et le jeu de données pour que l’équipe comprenne ce que couvrent les résultats.

Tenez des listes séparées pour les corrections et les nouvelles idées. Une exigence critique pour le lancement qui échoue exige une correction et un nouveau test ; une amélioration utile peut attendre dans le backlog ultérieur sans élargir discrètement la première version.

À avoir sous la main : un rapport d’acceptation et une décision sur le pilote, incluant les approbations pour les problèmes qui subsistent.

15. Préparer les collaborateurs et autoriser le lancement

Aidez les collaborateurs à se sentir prêts pour le changement, et réunissez l’équipe pour une décision de lancement claire.

Formez les éditeurs, les administrateurs et le personnel de support, et confirmez qu’ils peuvent réaliser les tâches qui leur sont attribuées.
Préparez des consignes pour les collaborateurs expliquant où se connecter, ce qui a changé de place, pourquoi utiliser l’intranet et où obtenir de l’aide.
Planifiez la communication de lancement pour tous les groupes concernés, y compris les collaborateurs hors des canaux d’e-mail professionnel.
Attribuez la permanence du jour du lancement et du support initial, un canal de retours et des contacts d’escalade des incidents.
Confirmez que les responsables du contenu, des accès, de la reprise, des intégrations, des tests et de l’exploitation ont fourni leurs preuves de préparation.
Tenez une revue go/no-go documentée couvrant les points bloquants, les risques acceptés, le calendrier de bascule, les déclencheurs de retour arrière et qui peut l’autoriser.

Donnez aux participants l’occasion de s’exercer pendant la formation. Demandez aux éditeurs de publier et de corriger du contenu, aux administrateurs de réaliser les tâches de gestion de comptes qui leur incombent, et au personnel de support de traiter un problème d’accès réaliste.

Choisissez des canaux de communication que les collaborateurs peuvent réellement atteindre. Selon l’organisation, il peut s’agir de briefings par les responsables d’équipe, de passations entre équipes postées, d’instructions de connexion imprimées ou des canaux existants sur le lieu de travail.

Lors de la revue go/no-go, partagez les résultats de test et les approbations pertinents plutôt que de simples pourcentages d’avancement. Consignez qui a pris la décision et quand, quels risques ont été acceptés et ce qui amènerait l’équipe à interrompre ou annuler le lancement.

À avoir sous la main : une décision de lancement approuvée et un plan de transition avec des personnes désignées. Laissez l’état de préparation, et pas seulement le calendrier, guider la décision finale.

16. Exploiter, améliorer et retirer l’ancien intranet

Continuez à écouter après le lancement, prenez soin du service et retirez les anciens outils lorsque votre équipe est prête à s’en séparer en toute sécurité.

Confirmez après la bascule que l’accès des collaborateurs, les tâches clés, les intégrations, les notifications et la supervision fonctionnent en production.
Passez en revue les premières demandes de support et les retours des collaborateurs, et attribuez des responsables aux problèmes récurrents.
Comparez les indicateurs de succès convenus à leurs valeurs de référence et planifiez les revues suivantes.
Inscrivez les revues de contenu, les revues d’accès, l’application des correctifs, les tests de reprise et les contrôles de capacité au calendrier d’exploitation.
Tenez un backlog d’améliorations priorisé et examinez les coûts et les besoins de support avant d’ajouter de nouvelles fonctionnalités.
Retirez l’ancien intranet et les services redondants uniquement après que les responsables ont approuvé la conservation, l’accès aux archives, les redirections et la clôture des contrats.

Revenez aux tests de tâches des collaborateurs définis dans le business case. Si les politiques restent difficiles à trouver, examinez les termes de recherche, les contenus en double, la navigation et les permissions avant de conclure qu’une nouvelle fonctionnalité est la solution.

Utilisez un diagnostic intranet pour guider les discussions ultérieures sur ce qui fonctionne et là où les collaborateurs ont encore besoin d’aide. Priorisez les améliorations selon l’impact métier, les éléments factuels, le coût et les besoins de support continu.

Il est inutile de précipiter le retrait de l’ancienne plateforme. Il peut intervenir après la période de support initial. Confirmez l’accès aux archives et les décisions de conservation avant de supprimer l’infrastructure ou de clôturer les contrats.

À avoir sous la main : une passation terminée, des revues planifiées et l’approbation du retrait de l’ancien système. Le lancement est un jalon ; l’entretien de l’intranet, lui, continue.

Prêt à transformer la checklist en plan de mise en œuvre?

Apportez cette checklist, les tâches des collaborateurs qui comptent le plus pour votre équipe et vos exigences d’intégration à une démo d’Open Intranet.

Ensemble, nous pouvons explorer ce qui peut être configuré, ce qui doit être connecté et quels écarts restants nécessitent réellement du développement. Vous disposerez d’un point de départ plus clair pour le périmètre, les coûts, les responsabilités et la préparation au lancement avant de vous engager sur une date de livraison ou un budget.