Pourquoi 60 % des projets IT échouent dès la phase de cadrage
Le cahier des charges fonctionnel d'un projet informatique est le document que tout le monde dit écrire et que personne ne rédige vraiment. Résultat : selon le Standish Group CHAOS Report 2023, seulement 31 % des projets IT sont livrés dans les délais et le budget initiaux. Les 69 % restants souffrent de dépassements, de périmètre flou, ou sont purement abandonnés. La cause principale citée dans 37 % des cas d'échec : des spécifications insuffisantes ou ambiguës.
Un CdC fonctionnel solide n'est pas un document bureaucratique. C'est votre outil de pilotage, votre référence contractuelle, et votre protection juridique si le prestataire livre quelque chose d'inutilisable. Il détermine ce que vous allez commander avant même de choisir qui va le réaliser.
Pour en savoir plus sur la sélection d'un prestataire, consultez notre guide sur nos services consulting.
CdC fonctionnel vs CdC technique : la distinction qui change tout
Beaucoup de dirigeants confondent les deux. La distinction est pourtant fondamentale :
| Document | Répond à | Rédigé par | Destiné à |
|---|---|---|---|
| CdC Fonctionnel | QUOI ? Pour qui ? Pourquoi ? | Maîtrise d'ouvrage (vous) | Prestataires, appel d'offres |
| CdC Technique | COMMENT ? Avec quoi ? En combien de temps ? | Maîtrise d'œuvre (prestataire) | Équipes de développement |
Vous, en tant que maître d'ouvrage, êtes responsable du CdC fonctionnel. Personne d'autre ne peut décrire vos besoins métier à votre place. Si vous déléguez cette étape au prestataire, vous l'autorisez implicitement à définir lui-même ce qu'il va vous livrer — et à facturer la différence.
Les 12 sections incontournables d'un CdC fonctionnel
1. Contexte et présentation de l'entreprise
Décrivez votre activité, votre secteur, votre taille, votre organisation. Un prestataire qui comprend votre métier fera de meilleures propositions. Incluez : effectif, chiffre d'affaires, secteur d'activité, implantations géographiques, interlocuteurs clés du projet.
2. Objectifs du projet (SMART)
Chaque objectif doit être Spécifique, Mesurable, Atteignable, Réaliste, Temporel. Évitez les formulations vagues comme "améliorer la productivité". Préférez : "Réduire le temps de traitement des commandes de 48h à 4h d'ici le 1er trimestre 2026."
3. Périmètre fonctionnel (in/out scope)
Listez explicitement ce qui est inclus dans le projet ET ce qui en est exclu. Cette section prévient 80 % des litiges sur les avenants. Un prestataire ne peut pas facturer un module "hors scope" si vous avez clairement défini les limites.
4. Description des utilisateurs et personas
Qui va utiliser le système ? Définissez chaque profil d'utilisateur : rôle, niveau technique, fréquence d'utilisation, contraintes (terrain, mobilité, handicap). Un ERP utilisé par des magasiniers sur tablette n'a pas les mêmes exigences UX qu'un outil analytique pour la direction financière.
5. Cartographie des processus actuels (AS-IS)
Documentez comment vous travaillez aujourd'hui, avant toute transformation. Cette cartographie AS-IS sert de référence pour valider que le nouveau système améliore réellement les processus existants. Elle révèle aussi les dysfonctionnements que vous ne voulez surtout pas reproduire dans le futur système.
6. Description des fonctionnalités (user stories ou cas d'usage)
C'est le cœur du document. Chaque fonctionnalité doit être décrite selon le format user story :
Format user story : En tant que [type d'utilisateur], je veux [action/fonctionnalité] afin de [bénéfice/objectif].
Exemple concret :
- En tant que commercial terrain, je veux créer un devis depuis mon téléphone en moins de 3 minutes, afin de répondre au client pendant la visite sans attendre mon retour au bureau.
- En tant que responsable ADV, je veux recevoir une alerte automatique quand un devis dépasse 500 000 DZD, afin de valider les conditions commerciales avant envoi.
- En tant que directeur commercial, je veux visualiser le taux de transformation des devis par commercial sur le mois en cours, afin d'ajuster les objectifs hebdomadaires.
Numérotez chaque user story (US-001, US-002…) pour faciliter les échanges avec le prestataire et le suivi en recette.
7. Contraintes techniques et d'intégration
Listez les systèmes existants avec lesquels le nouveau projet doit s'interfacer : ERP, CRM, système de paie, logiciel comptable. Précisez les contraintes : OS cibles, navigateurs supportés, base de données existante, hébergement (cloud ou on-premise), bande passante disponible dans vos agences.
8. Exigences non-fonctionnelles (performance, sécurité, disponibilité)
C'est la section la plus souvent oubliée — et la plus source de conflits post-livraison. Définissez :
- Performance : temps de réponse maximum (ex. : toute page doit s'afficher en moins de 2 secondes avec 50 utilisateurs simultanés)
- Disponibilité : taux d'uptime requis (ex. : 99,5 % hors maintenance planifiée)
- Sécurité : authentification, gestion des droits, chiffrement des données sensibles, conformité à la loi 18-07 sur la protection des données personnelles
- Scalabilité : le système doit supporter une croissance de 200 % du volume de données sur 3 ans sans refonte architecturale
9. Livrables attendus et jalons
Définissez ce que vous attendez à chaque étape du projet. Un jalon sans livrable vérifiable n'est pas un jalon — c'est une date fictive. Exemples de livrables : maquettes validées, environnement de recette opérationnel, jeu de données de test chargé, documentation utilisateur, formation des référents internes.
10. Critères d'acceptation et recette
Comment allez-vous valider que le prestataire a bien livré ce qui était demandé ? Rédigez des scénarios de test pour chaque user story principale. La recette n'est pas une formalité — c'est le moment où vous décidez si vous payez le solde ou si vous ouvrez un contentieux.
11. Budget et modalités de paiement
Indiquez votre enveloppe budgétaire, les conditions de paiement souhaitées (jalons, réceptions, retenue de garantie), et les pénalités prévues en cas de retard. En Algérie, les marchés publics suivent une structure réglementée (CNRC) ; les contrats privés doivent néanmoins prévoir des mécanismes similaires de protection.
12. Planning et conditions générales
Date de démarrage souhaitée, date de mise en production cible, contraintes calendaires (fermetures, bilan fiscal, période d'activité intense à éviter). Précisez aussi les conditions de propriété intellectuelle, de confidentialité et de droit applicable.
Les 3 erreurs qui sabotent 80 % des CdC fonctionnels
- Absence d'exigences non-fonctionnelles : Le prestataire livre une application qui fonctionne en recette mais s'effondre en production avec 30 utilisateurs. Aucun recours possible si vous n'avez pas spécifié les exigences de performance.
- Critères d'acceptation vagues : "L'application doit être conviviale" n'est pas un critère d'acceptation. "Le formulaire de commande doit être complétable en moins de 4 clics depuis la page d'accueil" en est un.
- Pas de processus de gestion des changements : Sans procédure d'avenant formalisée, le scope creep est inévitable. Chaque modification en cours de projet doit faire l'objet d'un avenant signé avec impact chiffré sur délais et coûts.
📊 Standish Group CHAOS Report : les projets IT disposant d'un CdC fonctionnel complet avec critères d'acceptation définis ont un taux de succès de 62 %, contre 18 % seulement pour les projets démarrés sans spécifications formalisées.
FAQ — Cahier des charges fonctionnel projet informatique
Quelle est la longueur idéale d'un CdC fonctionnel ?
Il n'y a pas de nombre de pages idéal — il y a un niveau de précision idéal. Un projet ERP pour une PME de 50 personnes nécessite généralement 30 à 60 pages. Un module spécifique peut se décrire en 10 pages. L'objectif est que deux prestataires différents puissent répondre à l'appel d'offres en comprenant exactement la même chose.
Doit-on toujours faire rédiger le CdC par un consultant externe ?
Non, mais c'est fortement recommandé pour les projets dépassant 2 millions de DZD ou impliquant plusieurs métiers. Un consultant AMO apporte une méthodologie éprouvée, une neutralité vis-à-vis des prestataires, et une expérience des litiges qui permet d'anticiper les formulations ambiguës avant qu'elles ne coûtent cher.
Comment gérer les fonctionnalités découvertes en cours de projet ?
Tout ce qui n'est pas dans le CdC initial est hors scope et doit faire l'objet d'un avenant formalisé. Prévoyez dès le départ une procédure de gestion des évolutions : demande de changement écrite, évaluation d'impact par le prestataire sous 5 jours ouvrés, validation par le chef de projet client avant toute réalisation.
Le CdC fonctionnel est-il suffisant pour lancer un appel d'offres ?
Pour un appel d'offres privé, oui. Pour un marché public (communes, entreprises publiques, ministères), le dossier doit être complété par un CdC technique, un cahier des clauses administratives particulières (CCAP), et un bordereau des prix unitaires conformément à la réglementation des marchés publics algériens.
Combien de temps faut-il pour rédiger un CdC fonctionnel ?
Un CdC fonctionnel sérieux prend entre 3 et 6 semaines pour un projet de taille moyenne. Cette durée inclut les ateliers avec les utilisateurs, la modélisation des processus, les cycles de révision et la validation par la direction. Beeform Consulting livre un CdC complet en 10 jours ouvrés grâce à une méthodologie éprouvée d'ateliers structurés.
🐝 Beeform Consulting : nous rédigeons vos cahiers des charges fonctionnels avec une méthodologie structurée en ateliers — livraison garantie en 10 jours ouvrés, document prêt pour appel d'offres. Demander un devis →
