Sommaire
Un groupe industriel de taille intermédiaire mandate un intégrateur pour refondre son intranet. Six mois de projet, un budget conséquent, une équipe mobilisée. Le jour du lancement, la plateforme est techniquement irréprochable. Trois mois plus tard, le taux d’utilisation plafonne à 18 %. La direction communication reçoit des retours cinglants des équipes terrain : « On ne trouve rien », « C’est trop compliqué », « Je préfère appeler ma collègue directement. » Bilan de l’audit post-lancement ? Le cahier des charges ne mentionnait à aucun moment les usages réels des collaborateurs. Il décrivait des fonctionnalités. Pas des besoins.
Cette histoire n’est pas une exception. 57 % des collaborateurs ne voient aucun intérêt dans l’intranet de leur entreprise, et 40 % des intranets n’offrent pas de retour sur investissement faute d’adoption suffisante. Les causes ? Toujours les mêmes. 29 % des échecs sont imputables à une direction floue, 25 % à des objectifs peu clairs, 22 % à une expérience utilisateur médiocre, et 18 % à un manque de personnalisation.
Ce qui est frappant dans ces chiffres, c’est qu’ils pointent tous vers la même origine : un cahier des charges insuffisant. Pas un problème de technologie. Pas un problème de budget. Un problème de méthode, en amont, avant que la moindre ligne de code ne soit écrite. Cet article est un guide pratique pour construire ce document différemment — de façon à ce qu’il serve vraiment à quelque chose.
Pourquoi la plupart des cahiers des charges d'intranet échouent avant même le lancement
Il y a un paradoxe troublant dans la façon dont la plupart des organisations abordent leur projet intranet. On passe des semaines à comparer des éditeurs, à négocier des licences, à choisir entre SharePoint, Jalios ou une solution sur mesure — et quelques jours à peine à rédiger le document qui est censé guider tout le reste.
Le cahier des charges est souvent traité comme une formalité administrative. Un document qu’on rédige pour « avoir quelque chose à envoyer aux prestataires ». Résultat : il ressemble à un catalogue de fonctionnalités souhaités, rédigé par la DSI, relu par la direction communication, et transmis à des intégrateurs qui s’en servent pour estimer un budget. Personne, dans ce processus, n’a vraiment interrogé les 200 ou 2 000 personnes qui vont utiliser la plateforme au quotidien.
Les erreurs les plus fréquentes qui fragilisent un cahier des charges informatique sont les suivantes : des objectifs trop vagues sources d’interprétations divergentes, des délais irréalistes générant des tensions, une absence de hiérarchisation des besoins rendant difficile la comparaison entre plusieurs réponses, une cybersécurité insuffisamment cadrée, et surtout la non-intégration des utilisateurs finaux entraînant un décalage entre la solution livrée et les usages réels.
Ce dernier point est le plus dommageable. Un intranet conçu sans les utilisateurs est un intranet conçu pour une entreprise imaginaire. Les fonctionnalités listées reflètent ce que la direction pense que les équipes veulent — rarement ce qu’elles vivent vraiment au quotidien.
Avant d'écrire une seule ligne : la phase de recueil qu'on saute toujours
Interroger les vrais utilisateurs, pas seulement les décideurs
Une bonne façon de démarrer est d’effectuer une enquête interne qui recense les besoins opérationnels et technologiques, d’interroger les collaborateurs et d’explorer des sites existants via un benchmark, tout en recherchant l’utilisation passée et actuelle des technologies intranet en place.
Concrètement, ça ressemble à quoi ? À des entretiens semi-directifs avec des profils variés — pas seulement les managers et les assistantes de direction, mais aussi les techniciens terrain, les commerciaux nomades, les équipes RH, les nouveaux arrivants. On leur pose des questions simples et révélatrices : « Comment trouvez-vous une information aujourd’hui ? » « Combien de fois par semaine consultez-vous l’intranet actuel ? » « Quelle est la chose qui vous fait perdre le plus de temps dans votre quotidien et qu’un intranet pourrait résoudre ? » « Qu’est-ce que vous n’utilisez jamais sur la plateforme actuelle et pourquoi ? »
Ces entretiens produisent quelque chose d’inestimable : des verbatims concrets, des irritants réels, des usages que personne n’avait anticipés. Une assistante administrative qui passe 45 minutes par semaine à retrouver la dernière version d’un bon de commande parce que les dossiers partagés sont désorganisés. Un commercial itinérant qui n’accède pas à l’intranet depuis son téléphone et utilise un groupe WhatsApp avec ses collègues pour s’échanger les informations urgentes. Un nouveau collaborateur qui, après trois semaines, ne sait toujours pas où trouver la politique de remboursement des frais.
Ces situations décrivent des besoins réels. Et ces besoins doivent structurer le cahier des charges — pas l’inverse.
Auditer l'existant sans complaisance
Avant de définir ce que le futur intranet doit faire, il faut comprendre pourquoi l’actuel ne fonctionne pas. L’erreur classique est de reproduire l’existant dans le nouvel outil. On change d’intranet pour transformer les pratiques, pas pour les figer. Chaque processus mérite d’être questionné : est-il toujours pertinent ? Répond-il à un besoin métier réel ou à une habitude ?
Un audit de l’existant doit produire trois livrables concrets : une cartographie des contenus actuels (qu’est-ce qui existe, qui le maintient, quand a-t-il été mis à jour pour la dernière fois), une analyse des statistiques d’usage si elles existent (quelles pages sont visitées, quelles fonctionnalités sont ignorées, quels mots-clés les utilisateurs tapent dans le moteur de recherche interne sans trouver de résultat), et une liste des fonctionnalités « fantômes » — celles qui ont été intégrées parce que « ça semblait utile » mais que personne n’utilise vraiment. Cette liste est souvent la plus longue. Et la plus révélatrice.
Les sections incontournables d'un cahier des charges d'intranet qui tient la route
Une fois le recueil terminé, la rédaction peut commencer. Voici les sections qui doivent absolument figurer dans le document — et ce qu’elles doivent contenir pour être réellement utiles.
Le contexte et les objectifs : la section que tout le monde rédige mal
La première section d’un cahier des charges est censée expliquer pourquoi ce projet existe. Dans la plupart des documents, elle ressemble à ça : « Notre entreprise souhaite refondre son intranet afin d’améliorer la communication interne et de favoriser la collaboration entre les équipes. » Inutile. Tout le monde peut écrire cette phrase. Elle ne dit rien à un prestataire sur ce qui est vraiment attendu.
Une bonne section « contexte et objectifs » doit répondre à des questions précises : Quelle est la taille de l’entreprise, combien de sites, combien de collaborateurs, quelle répartition géographique ? Quel est le problème business que cet intranet est censé résoudre — pas en termes génériques, mais de façon chiffrée si possible ? « Nos équipes passent en moyenne 20 % de leur temps à chercher de l’information » ou « notre onboarding dure actuellement 6 semaines et les nouveaux arrivants identifient le manque d’accès aux ressources comme le premier frein à leur montée en compétences ». Et enfin : comment mesurera-t-on le succès ? Quels indicateurs, dans 6 mois, diront que le projet a réussi ou échoué ?
Un cahier des charges efficace se concentre sur le QUOI et le POURQUOI, pas le COMMENT. Il laisse l’équipe technique proposer les meilleures solutions plutôt que de brider sa créativité en spécifiant l’implémentation détaillée dès le départ. La section « contexte » est le lieu naturel où cette philosophie s’applique : on décrit le problème, pas la solution.
Les personas utilisateurs : l'outil le plus sous-utilisé du cahier des charges intranet
Après avoir identifié les objectifs, il est important de définir le public cible pour lequel l’intranet sera conçu. Cela comprend les différents types d’utilisateurs, les groupes ayant différents rôles et niveaux d’autorité dans l’organisation, ainsi que les visiteurs externes éventuels.
Mais « définir le public cible » ne signifie pas simplement lister les services de l’entreprise. Ça signifie construire des personas — des profils types d’utilisateurs avec leurs contraintes réelles, leurs niveaux de maîtrise numérique, leurs appareils de connexion, leurs usages quotidiens. Au minimum trois ou quatre personas distincts : le collaborateur de bureau qui utilise un ordinateur fixe toute la journée et navigue sur l’intranet régulièrement, le technicien terrain qui accède au réseau depuis son smartphone entre deux interventions, le manager qui publie des informations et doit approuver des processus, et le nouveau collaborateur en période d’intégration qui a des besoins très spécifiques dans ses premières semaines.
Ces personas ne sont pas une fioriture pédagogique. Ils sont la grille de lecture que le prestataire va utiliser pour concevoir l’architecture de l’information, prioriser les fonctionnalités et dimensionner l’interface mobile. Un intranet conçu pour « tous les collaborateurs » finit souvent par ne convenir vraiment à personne.
Les fonctionnalités : prioriser plutôt qu'énumérer
C’est là que la plupart des cahiers des charges déraillent. On liste tout ce qu’on aimerait avoir — annuaire, gestion documentaire, actualités, espaces collaboratifs, formulaires RH, base de connaissances, onboarding digital, intégrations avec les outils métiers, moteur de recherche avancé, application mobile, chatbot, gestion des congés… La liste s’allonge. Le budget explose. Et personne n’arbitre.
Les sections fonctionnelles doivent distinguer les fonctionnalités attendues comme l’annuaire d’entreprise, la gestion des événements, les espaces de collaboration, les flux d’actualités, des fonctionnalités spécifiques à intégrer comme Microsoft Teams, les outils RH ou la gestion documentaire. Mais surtout, elles doivent hiérarchiser.
La méthode MoSCoW est simple et efficace pour ça. Chaque fonctionnalité est classée dans l’une des quatre catégories suivantes : Must Have (indispensable au lancement), Should Have (important mais non bloquant), Could Have (souhaitable si le budget le permet), et Won’t Have (exclu du périmètre de ce projet). Cette matrice force les arbitrages que personne ne veut faire et que tout le monde doit faire.
Un exemple concret : la gestion documentaire est presque toujours un Must Have. La gamification avec des badges et des classements est souvent un Could Have. Le chatbot IA est parfois un Won’t Have pour une première version — non parce qu’il est inutile, mais parce qu’il nécessite une maturité de contenu que la plateforme n’aura pas dans les six premiers mois.
Les exigences techniques : ce qu'il faut préciser sans entrer dans la technique
Il est important de prendre en compte des aspects tels que la sécurité, la protection des données et la gestion des utilisateurs lors de la définition de l’intranet idéal. Les contraintes techniques incluent notamment les besoins en matériel, logiciels, serveurs et méthodes d’authentification.
En pratique, les points techniques non négociables à formaliser dans le cahier des charges sont les suivants. L’authentification : SSO (Single Sign-On) obligatoire pour ne pas multiplier les mots de passe, intégration avec l’Active Directory ou l’annuaire LDAP existant. La compatibilité : quels navigateurs, quels systèmes d’exploitation, quelle performance sur mobile et sur des connexions dégradées (les équipes terrain ne sont pas toujours sur du 5G). L’hébergement : solution cloud ou on-premise, éditeur français ou européen si la souveraineté des données est un enjeu. Les intégrations : quels outils métiers existants doivent pouvoir « parler » à l’intranet — SIRH, outil de gestion des congés, plateforme de formation, suite bureautique. Et la sécurité : conformité RGPD, gestion des droits par profil, traçabilité des accès aux documents sensibles.
Ces exigences ne sont pas des détails techniques réservés à la DSI. Elles ont un impact direct sur le budget, sur les délais, et sur l’expérience utilisateur finale. Les ignorer dans le cahier des charges, c’est s’assurer de devoir les négocier en cours de projet — dans des conditions bien moins favorables.
Les erreurs de rédaction qui coûtent cher
Quelques patterns reviennent avec une régularité décourageante dans les cahiers des charges qui génèrent des projets problématiques.
Rédiger le cahier des charges en silo
La DSI rédige la partie technique, la communication la partie éditoriale, les RH ajoutent leurs fonctionnalités spécifiques — et personne ne fait la synthèse. Un cahier des charges IT efficace est un exercice collaboratif qui engage plusieurs parties prenantes : les métiers expriment leurs attentes, la DSI apporte son expertise technique et la maîtrise d’ouvrage veille à la cohérence globale. Sans chef d’orchestre clairement identifié, le document devient un assemblage incohérent de listes de souhaits.
Confondre fonctionnalités et besoins
« Nous avons besoin d’un forum » n’est pas un besoin. C’est une solution à un besoin qu’on n’a pas encore exprimé. Le besoin réel est peut-être : « Les équipes terrain ont besoin de pouvoir poser des questions techniques et obtenir des réponses rapides de leurs pairs sans passer par le management. » Ce besoin peut être résolu par un forum, un espace de questions-réponses, un canal Slack intégré, ou autre chose. Le cahier des charges qui formule le besoin laisse le prestataire proposer la meilleure solution. Celui qui spécifie la fonctionnalité ferme le débat — parfois à mauvais escient.
Négliger la gouvernance éditoriale
Sous-estimer la conduite du changement
Le chapitre que personne ne rédige : les indicateurs de succès
Un bon cahier des charges d’intranet se termine par une chose que presque aucun document n’intègre : la définition des indicateurs qui permettront de savoir, six mois après le lancement, si le projet a réussi.
Ces indicateurs ne sont pas des métriques techniques. Ce sont des indicateurs d’usage et d’impact business. Les bons indicateurs pour piloter un intranet vont bien au-delà du simple nombre de pages vues : ils permettent de suivre l’usage, l’engagement, les comportements de recherche et les actions réalisées après consultation d’une information.
Concrètement, un tableau de bord intranet pertinent suit au minimum : le taux d’utilisateurs actifs hebdomadaires rapporté à l’effectif total (un intranet sain vise 60 à 70 % d’actifs réguliers), la fréquence de connexion par profil (le collaborateur de bureau et le technicien terrain n’ont pas les mêmes patterns), le taux de recherches sans résultat (un indicateur direct de la qualité de l’architecture de l’information et du moteur de recherche), et des indicateurs d’impact métier comme le temps moyen pour trouver un document ou le taux de complétion du parcours d’onboarding.
Comme le formulent bien les praticiens de ce sujet : « Le bon indicateur, c’est celui que vous pouvez expliquer à votre COMEX en deux phrases. » Si vous ne savez pas comment mesurer le succès de votre intranet avant même de le lancer, vous ne saurez pas non plus comment le piloter après.
Un mot sur le budget : comment le cadrer sans se tromper
Le budget d’un projet intranet est l’une des rubriques les plus délicates du cahier des charges — parce qu’il est difficile d’estimer sans avoir d’abord défini le périmètre, et difficile de définir le périmètre sans avoir une enveloppe en tête. Ce cercle n’est pas insoluble, mais il demande de la méthode.
La bonne pratique consiste à exprimer une enveloppe globale en distinguant clairement les coûts de mise en œuvre (intégration, paramétrage, migration des contenus existants, formation des administrateurs) des coûts récurrents (licences, hébergement, maintenance, évolutions). Un prestataire qui ne fait pas cette distinction dans son offre mérite d’être interrogé.
Ce que le cahier des charges doit préciser sur le budget : l’enveloppe globale disponible (pour éviter de recevoir des offres hors sol), la répartition souhaitée entre développement et accompagnement au changement, et les critères de priorisation si des arbitrages doivent être faits entre fonctionnalités pour rester dans l’enveloppe. Ce dernier point rejoint directement la matrice MoSCoW évoquée plus haut. Le budget et les priorités fonctionnelles doivent être rédigés ensemble, pas dans des sections étanches.
Ce que le cahier des charges ne peut pas faire à votre place
Aussi bien construit soit-il, un cahier des charges ne garantit pas le succès d’un intranet. Il pose les conditions nécessaires — mais pas suffisantes.
Ce que le document ne peut pas substituer : l’implication réelle de la direction dans le projet (et pas seulement dans sa validation formelle), une stratégie éditoriale vivante qui fait que la plateforme reste à jour six mois après le lancement, des ambassadeurs internes identifiés et formés pour embarquer les équipes, et une culture d’entreprise qui valorise le partage d’information plutôt que sa rétention.
Si la direction utilise l’intranet dès le premier jour, les collaborateurs suivront l’exemple. C’est aussi simple et aussi difficile que ça. Un intranet n’est pas qu’un outil technique. C’est un signal organisationnel. Et ce signal doit venir d’en haut — indépendamment de la qualité du cahier des charges.
Le groupe industriel de notre histoire d’ouverture a refait l’exercice. Pas de refonte technologique cette fois. Un nouveau cahier des charges, construit différemment : quinze entretiens utilisateurs menés sur deux semaines, un audit des statistiques d’usage de l’intranet existant, une réunion d’arbitrage avec la direction pour hiérarchiser les fonctionnalités, et une section « indicateurs de succès » rédigée avant même que le projet démarre. Résultat, neuf mois plus tard : 71 % de taux d’utilisateurs actifs hebdomadaires. Les équipes terrain se connectent depuis leur mobile. Les nouveaux arrivants trouvent les ressources d’onboarding en moins de deux minutes.
La technologie n’avait pas changé. La méthode, si.
Un cahier des charges d’intranet vraiment efficace ne garantit pas un bon intranet. Mais un intranet sans bon cahier des charges ne sera presque jamais vraiment bon. C’est le prix de la rigueur en amont.
