Cahier des charges GED : modèle complet et grille de notation
Un modèle de cahier des charges GED prêt à adapter, section par section, avec des tableaux d'exigences et une grille d'évaluation pondérée pour comparer les offres.
Un cahier des charges GED décrit ce que votre future solution de gestion électronique de documents doit faire, dans quel contexte et selon quels critères vous choisirez. Il sert à trois choses : aligner les parties prenantes internes, obtenir des réponses comparables des éditeurs ou intégrateurs, et disposer d’une référence contractuelle une fois la solution choisie.
Un bon cahier des charges tient en une douzaine de sections : contexte, périmètre, volumétrie, exigences fonctionnelles, exigences techniques, sécurité, souveraineté, réversibilité, intégrations, migration, support, puis critères de notation. Chaque exigence porte un identifiant, une priorité et un moyen de vérification.
Ce modèle suit cet ordre. Chaque section indique ce qu’il faut écrire, donne des exemples de formulation et signale les oublis fréquents. Les tableaux sont à copier puis à compléter avec vos propres chiffres.
Avant de rédiger : trois règles simples
Décrivez des besoins, pas des écrans. « Retrouver un contrat fournisseur en moins de trente secondes à partir du nom du fournisseur ou d’un mot du texte » est une exigence vérifiable. « Une barre de recherche en haut à droite » n’en est pas une.
Priorisez tout. Sans priorité, chaque candidat répond « oui » à tout et vous ne pouvez plus départager. La méthode MoSCoW fonctionne bien : Must (indispensable), Should (important), Could (souhaitable), Won’t (hors périmètre de cette phase).
Rendez chaque exigence vérifiable. Pour chacune, demandez-vous comment vous la testerez lors de la démonstration ou du pilote. Si vous ne savez pas, reformulez.
Le cahier des charges s’inscrit dans une démarche plus large, décrite dans notre guide réussir un projet GED en 8 étapes : il vient après le cadrage et l’audit de l’existant, jamais avant.
Structure du modèle
| N° | Section | Contenu attendu | Contributeurs |
|---|---|---|---|
| 1 | Contexte et objectifs | Organisation, problème à résoudre, objectifs mesurables | Direction, chef de projet |
| 2 | Périmètre | Services, types de documents, processus concernés | Chef de projet, métiers |
| 3 | Volumétrie | Utilisateurs, stock, flux, croissance | DSI, métiers |
| 4 | Exigences fonctionnelles | Tableau priorisé | Métiers, référent documentaire |
| 5 | Exigences techniques | Hébergement, architecture, performances | DSI |
| 6 | Sécurité | Authentification, droits, chiffrement, traçabilité | RSSI, DSI |
| 7 | Souveraineté | Localisation, droit applicable, sous-traitants | Direction, DPO, juridique |
| 8 | Réversibilité | Export, formats, accompagnement de sortie | DSI, juridique |
| 9 | Intégrations | Annuaire, messagerie, ERP, CRM, API | DSI |
| 10 | Migration | Sources, volumes, métadonnées à reprendre | DSI, référent documentaire |
| 11 | Support et formation | Niveaux de service, formation, maintenance | Chef de projet |
| 12 | Réponse et notation | Pièces à fournir, grille pondérée, calendrier | Chef de projet, achats |
1. Contexte et objectifs
Présentez votre organisation en quelques lignes : activité, effectif, nombre de sites, organisation informatique. Décrivez ensuite la situation actuelle sans jugement : serveur de fichiers partagé, documents dans les messageries, archives papier, outil existant en fin de vie.
Formulez enfin des objectifs mesurables. Exemples :
- réduire le temps de recherche d’un document client ;
- supprimer les doublons entre le serveur de fichiers et les pièces jointes des courriels ;
- dématérialiser le circuit de validation des factures fournisseurs ;
- appliquer les durées de conservation et tracer les accès aux documents sensibles.
Ces objectifs serviront à mesurer le succès du projet. Ils doivent donc être assortis d’un indicateur, même approximatif.
2. Périmètre
Listez ce qui est dans le périmètre et, surtout, ce qui n’y est pas. Un périmètre flou est la première cause de dérive des devis.
| Élément | Inclus | Exclu | Remarque |
|---|---|---|---|
| Services concernés | Comptabilité, RH, direction commerciale | Production | Production en phase 2 |
| Types de documents | Contrats, factures, dossiers salariés, procédures | Plans techniques | |
| Processus | Validation des factures, gestion des contrats | Gestion des congés | |
| Archives papier | Contrats en cours | Archives de plus de 10 ans | À traiter à part |
Si vous disposez déjà d’un plan de classement, joignez-le en annexe. Sinon, prévoyez de le construire avant ou pendant le projet : notre guide pour construire un plan de classement détaille la méthode.
3. Volumétrie
Les candidats dimensionnent leur offre, et souvent leur prix, sur ces chiffres. Donnez des valeurs même estimées, en précisant qu’elles le sont.
| Indicateur | Valeur actuelle | À 3 ans | Source ou méthode |
|---|---|---|---|
| Utilisateurs nommés | Annuaire | ||
| Utilisateurs simultanés (pic) | Estimation | ||
| Utilisateurs externes (clients, partenaires) | |||
| Volume de documents existants (nombre et Go) | Analyse du serveur de fichiers | ||
| Flux entrant mensuel (documents et Go) | |||
| Taille moyenne et maximale d’un fichier | |||
| Part de documents numérisés (images, PDF non OCRisés) | |||
| Pages papier à numériser | Métrage linéaire × estimation |
4. Exigences fonctionnelles
Présentez-les sous forme de tableau, avec un identifiant stable. Les candidats répondent ligne par ligne : « standard », « paramétrage », « développement spécifique » ou « non couvert ». Cette dernière colonne est souvent plus instructive que le « oui » lui-même.
| ID | Exigence | Priorité | Vérification |
|---|---|---|---|
| F01 | Dépôt de documents par glisser-déposer, par lot et par courriel | Must | Démonstration |
| F02 | Métadonnées configurables par type de document, avec champs obligatoires | Must | Démonstration |
| F03 | Recherche plein texte, y compris dans les documents numérisés (OCR) | Must | Test sur vos fichiers |
| F04 | Gestion des versions avec historique et restauration | Must | Démonstration |
| F05 | Droits d’accès par dossier, par groupe et par document | Must | Scénario de test |
| F06 | Visualisation sans téléchargement des formats courants (PDF, Office, images) | Should | Démonstration |
| F07 | Circuits de validation paramétrables avec relances | Should | Scénario de test |
| F08 | Partage externe sécurisé (lien expirant, mot de passe) | Should | Démonstration |
| F09 | Signature électronique intégrée | Could | Démonstration |
| F10 | Application des durées de conservation et gestion du sort final | Should | Scénario de test |
| F11 | Édition collaborative de documents bureautiques | Could | Démonstration |
| F12 | Accès mobile | Could | Démonstration |
Pour F10, joignez votre référentiel de conservation, même provisoire : sans lui, les candidats ne peuvent pas décrire comment leur solution appliquera vos règles.
5. Exigences techniques
Décrivez vos contraintes, pas vos préférences. Les points habituels :
- mode d’hébergement accepté : SaaS mutualisé, instance dédiée managée, hébergement sur votre infrastructure, ou plusieurs options ;
- environnements : production, recette, éventuellement formation ;
- compatibilité postes : navigateurs, systèmes d’exploitation, client de synchronisation ;
- performances attendues, exprimées en temps de réponse sur des opérations précises ;
- disponibilité cible et fenêtres de maintenance ;
- sauvegarde : fréquence, rétention, tests de restauration, localisation des copies ;
- accessibilité : pour un organisme public, conformité attendue au référentiel RGAA.
6. Sécurité
La section sécurité doit permettre de vérifier les réponses, pas seulement de les lire.
| ID | Exigence | Priorité |
|---|---|---|
| S01 | Authentification unique (SSO) via votre fournisseur d’identité (OIDC ou SAML) | Must |
| S02 | Authentification multifacteur disponible | Must |
| S03 | Contrôle d’accès par rôles, principe du moindre privilège | Must |
| S04 | Chiffrement des flux (TLS) et des données stockées | Must |
| S05 | Option de chiffrement avec des clés gérées par le client | Could |
| S06 | Journal d’audit des accès et actions, exportable | Must |
| S07 | Politique de gestion des vulnérabilités et délai de correctif | Should |
| S08 | Résultats de tests d’intrusion récents communicables | Should |
| S09 | Procédure de notification des incidents de sécurité | Must |
Demandez les attestations et certifications que le candidat détient réellement, avec leur périmètre exact : une certification peut ne couvrir que l’hébergeur, pas l’éditeur ni le logiciel.
7. Souveraineté et localisation des données
Ce point est devenu un critère de choix à part entière. Posez des questions fermées :
- où sont hébergées les données, les sauvegardes et les journaux ?
- quelle est la nationalité de l’éditeur, de l’hébergeur et de leurs sociétés mères ?
- quels sous-traitants ultérieurs ont accès aux données, et depuis quels pays ?
- le candidat est-il soumis à une législation extraterritoriale permettant à une autorité étrangère d’exiger l’accès aux données ?
Si votre contexte impose un niveau de qualification particulier, citez-le explicitement. Notre article sur SecNumCloud, HDS et l’hébergement souverain aide à choisir le bon niveau d’exigence sans surdimensionner.
8. Réversibilité
C’est la section la plus souvent négligée, et celle qui coûte le plus cher quand on l’oublie. Exigez :
- un export complet des documents, de toutes leurs versions, des métadonnées, des droits et des journaux d’audit ;
- des formats ouverts et documentés pour cet export (fichiers originaux, métadonnées en CSV, JSON ou XML) ;
- la durée pendant laquelle les données restent accessibles après la fin du contrat ;
- les conditions financières de l’accompagnement à la sortie ;
- la suppression certifiée des données chez le prestataire à l’issue de la réversibilité.
Une solution construite sur des composants standards facilite cette sortie. Par exemple, OpenFilz (édité par l’équipe qui publie ce site) stocke ses métadonnées dans PostgreSQL et ses fichiers sur un stockage S3 ou un système de fichiers, et son cœur est publié sous licence AGPL-3.0 (voir la GED open source OpenFilz). Quel que soit le candidat, demandez une démonstration d’export plutôt qu’une simple déclaration.
9. Intégrations
Listez les applications avec lesquelles la GED doit échanger, le sens des flux et leur fréquence.
| Application | Sens du flux | Déclencheur | Priorité |
|---|---|---|---|
| Annuaire (Active Directory, Entra ID, LDAP) | Annuaire vers GED | Synchronisation | Must |
| Messagerie | Messagerie vers GED | Enregistrement d’un courriel | Should |
| ERP / comptabilité | Bidirectionnel | Validation d’une facture | Should |
| CRM | CRM vers GED | Création d’un dossier client | Could |
| Suite bureautique | Bidirectionnel | Ouverture et enregistrement | Must |
Demandez la documentation publique de l’API (REST, GraphQL), les mécanismes de notification (webhooks) et les éventuels coûts d’appel.
10. Migration
Décrivez chaque source : serveur de fichiers, outil existant, messageries, archives numérisées. Pour chacune, précisez le volume, l’état de rangement, les métadonnées à conserver (auteur, dates, versions) et les droits d’accès à reprendre.
Demandez aux candidats leur méthode : outils de reprise, gestion des doublons, conservation des dates d’origine, rapport de migration, possibilité de migration par vagues. Si des archives papier entrent dans le périmètre, traitez leur numérisation comme un lot distinct, avec son propre cahier des charges de numérisation.
11. Support, maintenance et formation
- Niveaux de service : horaires du support, canaux, délais de prise en charge et de résolution par niveau de gravité.
- Langue du support et de la documentation.
- Maintenance : fréquence des mises à jour, préavis, compatibilité ascendante, durée de support des versions.
- Formation : administrateurs, référents, utilisateurs ; formats (présentiel, distanciel, vidéos) ; supports réutilisables.
- Pénalités éventuelles en cas de non-respect des engagements.
12. Modalités de réponse et grille de notation pondérée
Précisez les pièces attendues (mémoire technique, réponse au tableau d’exigences, proposition financière détaillée sur trois ou cinq ans, planning, références) et le calendrier : questions, remise des offres, démonstrations, pilote éventuel.
Fixez la grille avant de recevoir les offres. Voici un exemple de pondération, à ajuster à vos priorités :
| Critère | Poids |
|---|---|
| Couverture fonctionnelle (exigences Must et Should) | 30 % |
| Sécurité et souveraineté | 20 % |
| Coût total sur 3 à 5 ans | 20 % |
| Réversibilité et ouverture (formats, API) | 10 % |
| Méthodologie de déploiement et de migration | 10 % |
| Support, formation, pérennité | 10 % |
Notez chaque critère sur une échelle courte, par exemple : 0 (non couvert), 1 (partiel ou spécifique), 2 (couvert par paramétrage), 3 (couvert en standard). Note pondérée = somme des (note ÷ 3 × poids).
Exemple fictif. Un candidat obtient 3 en fonctionnel, 2 en sécurité, 2 en coût, 3 en réversibilité, 2 en méthodologie et 1 en support. Sa note est : 30 + 13,3 + 13,3 + 10 + 6,7 + 3,3 = 76,6 sur 100.
Pour le critère coût, demandez un calcul du coût total de possession et non un simple prix annuel : notre guide combien coûte une GED détaille les postes à exiger.
À retenir
- Un identifiant, une priorité et un moyen de vérification pour chaque exigence.
- Des volumes chiffrés, même estimés : ils conditionnent les devis.
- La réversibilité et la souveraineté s’écrivent au départ, pas au moment de partir.
- Une grille de notation fixée avant l’ouverture des offres, confirmée par une démonstration sur vos propres documents.
Les erreurs fréquentes dans un cahier des charges GED
- Copier la liste de fonctionnalités d’un éditeur. Vous obtiendrez un cahier des charges biaisé qui ne décrit pas vos besoins.
- Tout classer en « indispensable ». Les réponses deviennent indiscernables.
- Oublier les utilisateurs externes (clients, experts-comptables, partenaires), qui changent souvent le modèle de licence.
- Sous-estimer la migration. Reprendre dix ans de serveur de fichiers est rarement un simple copier-coller.
- Ne pas prévoir de pilote. Une démonstration préparée par l’éditeur ne remplace pas un test sur vos documents avec vos utilisateurs.
- Ignorer les données personnelles. Les dossiers RH ou clients imposent des règles d’accès et de conservation ; notre article GED et RGPD les récapitule.
Questions fréquentes
Combien de pages doit faire un cahier des charges GED ?
Il n'y a pas de norme. Pour une PME, 10 à 20 pages bien structurées suffisent souvent ; une collectivité ou un groupe multi-sites ira plus loin, surtout sur la sécurité et les intégrations. L'important est que chaque exigence soit identifiée, priorisée et vérifiable, pas la longueur du document.
Faut-il imposer une solution technique dans le cahier des charges ?
Non, sauf contrainte réelle (base de données imposée par votre DSI, hébergement sur votre propre infrastructure, annuaire existant). Décrivez le besoin et le résultat attendu, et laissez les candidats proposer leur réponse. Imposer une technologie sans raison réduit la concurrence et peut, dans un marché public, poser un problème d'égalité de traitement.
Qui doit rédiger le cahier des charges d'une GED ?
Le chef de projet côté métier pilote la rédaction, avec la DSI pour les exigences techniques et de sécurité, le responsable des archives ou le référent documentaire pour le plan de classement et les durées de conservation, et le DPO pour les données personnelles. Faire relire le document par deux ou trois futurs utilisateurs évite les exigences hors-sol.
Comment comparer objectivement les réponses des éditeurs GED ?
Fixez la grille de notation et ses pondérations avant de lire les réponses, notez chaque critère sur une échelle courte (0 à 3 par exemple) et faites noter séparément par plusieurs évaluateurs. Complétez par une démonstration sur vos propres documents et, idéalement, un pilote : la note écrite seule ne suffit pas.
Existe-t-il un modèle de cahier des charges GED gratuit ?
Oui : la structure présentée dans cet article est réutilisable librement. Copiez les tableaux, remplacez les exemples par vos chiffres et supprimez les exigences qui ne vous concernent pas. Un modèle n'a de valeur que s'il est adapté à votre contexte.