Réponse courte. Un cahier des charges utile tient en neuf pages et ne contient presque pas de technique. Il dit quel problème l'application règle et pour qui, raconte cinq à huit parcours de bout en bout, trie les fonctions en trois colonnes, version 1, ensuite, jamais, donne un critère vérifiable par fonction de la version 1, et fixe à qui appartiennent le code et les comptes. Il ne choisit ni le langage, ni l'architecture, ni l'hébergeur : c'est le travail du prestataire, et un cahier des charges qui l'impose coûte plus cher. Envoyé à trois prestataires avec les mêmes six questions, il ramène des devis à 25 % près au lieu d'un écart de un à six.
Ce guide s'adresse au fondateur installé en France qui veut construire en Algérie ce qu'il a vu marcher à Lyon ou à Marseille, au grossiste qui veut une plateforme de commande pour ses détaillants, au gérant de clinique, d'école, de chaîne de magasins ou de société de transport qui a dit « il nous faut une appli » et à qui le premier prestataire a répondu « envoyez-nous votre cahier des charges ». Il dit ce que les études sur les projets informatiques mesurent, ce qu'un cahier des charges contient et ne contient pas, comment l'écrire en deux semaines, comment lire trois devis, et comment le calendrier 2027 s'organise pour qu'un pilote tourne avant l'été.
Ce que les chiffres disent
Le coût d'un besoin mal écrit est mesuré depuis longtemps. Dans son étude de 2014 sur la gestion des exigences, le Project Management Institute écrit que lorsqu'un projet n'atteint pas ses objectifs, une gestion inexacte des exigences en est la cause première dans 47 % des cas ; que 5,1 % de chaque dollar dépensé en projets est perdu pour cette seule raison, soit 51 millions de dollars pour chaque milliard ; et que « la collecte inexacte des exigences » était citée comme cause première d'échec par 37 % des organisations en 2014, contre 32 % en 2013. Ces enquêtes portent surtout sur de grandes organisations dans le monde ; les ordres de grandeur se transposent, pas les décimales.
La taille du projet compte autant que la qualité du document. L'étude menée en 2012 par McKinsey avec l'université d'Oxford sur plus de 5 400 projets informatiques de plus de 15 millions de dollars trouve qu'en moyenne ils dépassent leur budget de 45 %, leur délai de 7 %, et livrent 56 % de valeur en moins que prévu. À l'autre bout de l'échelle, le Standish Group, dont la méthode est discutée mais dont les proportions sont reprises partout, publiait en 2015 que 61 % des petits projets réussissent, contre 6 % des très grands. La leçon pour un cahier des charges d'application est directe : une version 1 courte, livrée et utilisée, vaut plus qu'une version complète promise ; c'est le tri des fonctions, pas la liste, qui fait le document.
Le contexte algérien ajoute ses propres lignes au cahier des charges. 51,63 millions d'abonnements 4G et 5G au deuxième trimestre 2026 selon l'ARPCE : les utilisateurs sont sur téléphone, en majorité sur Android, et le réseau manque encore dans l'entrepôt, le sous-sol ou la route de wilaya, ce qui fait du « hors ligne » une décision à écrire et non un détail. Le paiement par carte CIB et Edahabia passe par SATIM et demande un dossier porté par l'entreprise, pendant que le paiement à la livraison reste la norme ; l'arabe et le français cohabitent sur les mêmes écrans ; et l'hébergement, le nom de domaine et les comptes des stores doivent être au nom de l'entreprise, parce que nous voyons chaque mois des applications bloquées chez un développeur qui ne répond plus. Rien de tout cela n'est technique ; tout cela change le prix.
Ce qu'un cahier des charges contient, en six parties
Un cahier des charges d'application se lit en six parties, de la page de problème aux critères de réception, et la première est celle qui manque le plus souvent.
Le problème tient en une page et répond à quatre questions : qui perd quoi aujourd'hui, combien de fois par jour, avec quels outils, et ce que la version 1 doit changer, en chiffres. « Les détaillants commandent par téléphone et WhatsApp, 140 commandes par jour, quatre personnes les ressaisissent, 6 % d'erreurs de référence, la V1 doit ramener la ressaisie à zéro et les erreurs sous 1 % » dit plus à un prestataire que quarante fonctions. Les parcours racontent, rôle par rôle, ce qui se passe du début à la fin, avec le cas où ça rate : le détaillant commande à 22 h, le préparateur voit la commande à 6 h, le livreur la charge, le paiement est refusé, la commande est modifiée après validation. Cinq à huit parcours suffisent ; c'est d'eux que le prestataire tire les écrans, pas l'inverse. Les fonctions viennent ensuite, écrites dans le format né chez Connextra en 2001, « en tant que détaillant, je veux refaire ma commande de la semaine dernière en un geste, pour gagner dix minutes », et surtout triées : version 1, ensuite, jamais. La méthode DSDM, à l'origine du tri MoSCoW, recommande de ne pas mettre plus de 60 % de l'effort dans l'indispensable et de garder environ 20 % dans le souhaitable, pour qu'il reste de quoi absorber l'imprévu sans manquer la date.
Les données et les intégrations disent ce qui existe déjà et devra être repris ou relié : le fichier Excel des clients et des tarifs, le logiciel comptable, la caisse, l'envoi de SMS, WhatsApp, SATIM pour la carte. C'est souvent la ligne la plus sous-estimée des devis ; nous décrivons dans un guide à part comment on reprend les données d'un vieux logiciel sans arrêter l'activité. Les contraintes et la propriété fixent les langues, Android d'abord ou iOS en même temps, le hors ligne et pour qui, où sont hébergées les données, et au nom de qui sont le dépôt de code, les comptes Play et App Store, l'hébergement et le domaine. La réception dit comment on saura que c'est fini, par un critère par fonction ; donne une fourchette de budget plutôt que rien ; fixe la date du pilote ; et pose la question de l'année qui suit, qui maintient et pour combien par mois, que nous chiffrons dans le guide sur ce que coûte une application chaque année.
L'écrire en deux semaines, en six étapes
Le document s'écrit sans outil et sans prestataire, en une dizaine d'heures réparties sur deux semaines, dans cet ordre.
La page de problème se rédige en premier et se relit en dernier : si une fonction de la liste ne sert pas ce qui est écrit sur cette page, elle sort de la version 1. Les parcours se racontent à voix haute avec la personne qui fait le travail aujourd'hui, le préparateur, le vendeur, la secrétaire médicale ; on note ce qu'elle fait, pas ce qu'elle devrait faire, et on lui demande ce qui rate une fois par semaine. La liste puis le tri est l'étape qui décide du prix et du délai : on écrit tout, trente ou quarante lignes, puis on trie en trois colonnes, et la version 1 doit tenir sur une page. La règle qui aide le plus : une fonction n'entre en version 1 que si un parcours de la partie précédente ne peut pas se terminer sans elle.
Les écrans au crayon ne demandent aucun talent : six à dix rectangles dessinés à la main, un par étape des parcours, avec, pour chacun, une capture d'écran d'une application que vous aimez pour cet écran-là, celle de la liste, celle du panier, celle du suivi. C'est cela, et non « interface moderne et intuitive », qui dit au prestataire ce que vous attendez. Le critère par fonction est une phrase qui commence par « c'est fini quand » et qu'un tiers peut vérifier : « c'est fini quand un détaillant qui n'a jamais vu l'application passe une commande de dix lignes en moins de trois minutes sans aide ». La relecture à deux voix clôt l'écriture : un futur utilisateur et un développeur de confiance, ami, cousin, ancien collègue, lisent le document ; chaque passage qu'ils ne comprennent pas est réécrit, chaque question qu'ils posent devient une ligne.
«C'est le tri, pas la liste, qui fait un cahier des charges.»
Un exemple chiffré
Un exemple sur des hypothèses, à refaire avec vos chiffres : un grossiste en produits alimentaires, trois cents détaillants, qui veut une plateforme de commande.
La liste. Trente-huit fonctions au départ, issues de deux applications vues en France et d'une semaine d'idées : catalogue, commande, recommande, promotions, suivi de livraison, paiement carte, programme de points, chat, notation des livreurs, tableau de bord, et le reste. Le tri. Quatorze en version 1 : celles sans lesquelles les six parcours ne se terminent pas, catalogue avec tarifs par client, commande et recommande, validation par le préparateur, tournée du livreur, paiement à la livraison enregistré, état des impayés, rôles et accès, arabe et français, hors ligne pour la prise de commande du vendeur. Onze pour ensuite, dont la carte via SATIM, les promotions ciblées et le programme de points. Treize jamais, dont le chat, parce que WhatsApp existe, et la notation des livreurs, parce que le gérant les connaît tous.
Le document. Neuf pages : la page de problème, six parcours, la liste triée, huit écrans au crayon avec leurs références, un critère par fonction, les contraintes et la propriété, une fourchette de budget et la date du pilote. Les devis. La première demande, orale, « une appli de commande pour nos clients », avait ramené trois prix dans un rapport de un à six ; le même document envoyé aux mêmes prestataires, avec les six questions de la section suivante, ramène trois devis à 25 % près, et la différence restante s'explique par ce qui est compris, la reprise de l'Excel et la mise en ligne sur les stores. Le calendrier. Vingt semaines du premier jour d'écriture au pilote avec dix détaillants, avec une démonstration toutes les deux semaines à partir de la septième.
Six phrases qui rendent les devis incomparables
Les écarts entre devis viennent rarement du travail ; ils viennent de phrases que chaque prestataire lit à sa façon.
Chaque phrase de gauche est de bonne foi. « Une appli comme Yassir » décrit une expérience, pas un périmètre, et un prestataire y lit la géolocalisation en temps réel quand un autre y lit un formulaire de commande. « Paiement en ligne » recouvre en Algérie quatre chantiers sans rapport, de l'enregistrement du paiement à la livraison au dossier SATIM pour la carte CIB et Edahabia, que nous décrivons dans le guide technique d'intégration SATIM ; écrire lequel entre en version 1, et qui porte le dossier, change le devis du tout au tout. « Ça doit marcher partout » est la phrase la plus coûteuse : chaque « et », Android et iOS, web et mobile, en ligne et hors ligne, double une partie du travail, et la colonne de droite consiste simplement à choisir, pour la version 1, un côté de chaque « et ». Nous avons détaillé ces choix dans les sept décisions à prendre avant de créer une application.
Comparer trois devis, et ce qu'on laisse au prestataire
Trois devis se comparent avec six questions posées dans le même ordre à chacun, par écrit, avant de parler de prix.
Le périmètre et ce qui est compris rendent les prix comparables : un devis qui ne reprend pas vos quatorze fonctions une à une a chiffré autre chose, et un prix qui ne dit pas si les maquettes, les tests, la mise en ligne sur Play et App Store, la reprise de l'Excel et la formation sont dedans n'est pas un prix. La propriété se règle avant la signature et par écrit : dépôt de code, comptes Play et App Store, hébergement, nom de domaine, au nom de l'entreprise dès le premier jour, avec un accès pour le prestataire et non l'inverse ; le guide sur l'application bloquée chez un développeur disparu raconte ce qui arrive sinon. La méthode se vérifie par une seule chose : une démonstration toutes les deux semaines, sur un lien que vous ouvrez vous-même, de ce qui marche vraiment, et non d'une maquette. La suite est souvent la vraie différence entre devis : un prix par mois après la livraison, ce qu'il couvre, le délai de réponse en cas de panne. Les hypothèses disent ce qui fera bouger le prix, le nombre d'utilisateurs, qui fournit les contenus, qui porte le dossier SATIM ; un devis sans hypothèses en a quand même, il ne vous les a pas dites.
À l'inverse, un cahier des charges qui impose le langage, le framework, la base de données ou l'hébergeur coûte plus cher, parce qu'il retire au prestataire le choix qu'il maîtrise et lui laisse la responsabilité du résultat. Ce que vous décidez : le problème, les parcours, le tri, les langues, le hors ligne, où sont les données, à qui appartient quoi, la date. Ce que vous laissez : comment c'est construit. Un bon prestataire vous expliquera ses choix en une page et vous dira ce qu'ils impliquent pour la suite, par exemple ce que coûtent les services cloud et les clés d'IA payés depuis l'Algérie ; un prestataire qui refuse de les expliquer est une réponse en soi. Nous comparons les trois types de prestataires, freelance, agence et atelier d'ingénierie, dans un guide dédié.
«Un devis sans hypothèses en a quand même ; il ne vous les a pas dites.»
Vu en France : le cahier des charges fonctionnel et le sprint de cinq jours
En France, le cahier des charges est une institution. Il a sa norme, NF EN 16271, publiée en février 2013 sous l'indice X50-151, « Management par la valeur, expression fonctionnelle du besoin et cahier des charges fonctionnel », qui a remplacé la norme française de 2007 ; son principe tient en une phrase, exprimer le besoin en fonctions à rendre et non en solutions à construire, et c'est exactement ce que fait la page de problème et les parcours décrits plus haut. Les marchés publics y ajoutent le cahier des clauses techniques particulières, et tout fondateur qui a travaillé dans une entreprise française a vu passer un appel d'offres avec des critères de notation écrits. La diaspora arrive donc avec l'habitude ; ce qui change en Algérie, ce sont les lignes à écrire : le paiement à la livraison à côté de SATIM, l'arabe et le français sur le même écran, Android d'abord, le hors ligne, et la propriété des comptes.
L'autre pratique vue en France, et que les agences y vendent sous le nom d'atelier de cadrage, vient de Google Ventures : le design sprint, cinq jours pour cartographier le problème le lundi, esquisser le mardi, décider le mercredi, prototyper le jeudi et tester avec cinq clients le vendredi, une méthode que Jake Knapp a commencé à pratiquer chez Google en 2010 et formalisée chez GV à partir de 2012. Nous en gardons l'essentiel pour la phase de cadrage de la septième semaine : un prototype cliquable testé avec de vrais utilisateurs avant d'écrire une ligne de code, parce qu'une semaine de maquettes coûte moins qu'un mois de développement dans la mauvaise direction. Ce qui ne se transpose pas, c'est l'idée que cinq jours remplacent le cahier des charges : le sprint teste une solution, le cahier des charges dit quel problème elle doit résoudre et ce qu'elle ne fera pas.
Depuis la France : commander une application pour l'Algérie sans y être
Le fondateur installé en France a un avantage et un risque. L'avantage : il a vu l'application de référence fonctionner, il sait ce qu'un parcours réussi ressemble, et il a souvent l'habitude d'écrire. Le risque : il écrit le cahier des charges de l'application française et non de l'algérienne, avec le paiement par carte en version 1, le compte obligatoire au premier achat, l'iOS au même rang qu'Android et le réseau supposé partout. Les parcours doivent être racontés avec les personnes qui feront le travail à Sétif ou à Oran, par téléphone s'il le faut, et chaque hypothèse « comme en France » doit être vérifiée : qui a une carte, qui paie en espèces, qui a un iPhone, où le réseau manque.
Le second point est la distance avec le prestataire. Les six questions s'appliquent avec plus de rigueur encore : les comptes au nom de l'entreprise algérienne ou de la vôtre, jamais du prestataire ; une démonstration toutes les deux semaines sur un lien, à une heure fixe, et non des captures d'écran sur WhatsApp ; un accès au dépôt de code dès le premier mois ; une personne nommée qui répond. Le pilote se fait avec dix utilisateurs réels sur place, et la décision de la version 2 se prend sur leurs retours, pas sur l'avis du groupe familial. Si le projet est un SaaS, l'abonnement et son encaissement sont une partie du cahier des charges à part entière, que nous traitons dans le guide sur lancer un SaaS en Algérie.
Qui vous êtes, par où commencer
Le grossiste ou le distributeur commence par les parcours de ses détaillants et de ses livreurs, et par la ligne « données » : le fichier des tarifs par client est le cœur de la version 1. La clinique, le cabinet ou le laboratoire commence par le parcours du patient qui prend rendez-vous et de la secrétaire qui le reçoit, et par la ligne « propriété », parce que les données de santé ne peuvent pas être hébergées n'importe où. L'école ou le centre de formation commence par les trois rôles, parent, enseignant, administration, et par le paiement par tranches. La société de transport ou de livraison commence par le hors ligne et par ce que voit le dirigeant le soir.
Le fondateur de la diaspora commence par la page de problème, écrite pour l'Algérie et non pour la France, et par un premier parcours vérifié au téléphone avec un futur utilisateur. Le commerçant ou la chaîne de magasins commence par la caisse existante et par ce qu'elle doit envoyer à la plateforme. Dans tous les cas, la première semaine est la même : une page, cinq parcours, la liste, puis le tri. Le prestataire n'intervient qu'ensuite, et il doit pouvoir vous rendre, avant de signer, le cahier des charges relu, les trois options et leur prix total ; c'est ce que nous faisons, et c'est ce qu'il faut demander à chacun.
Le calendrier 2027
Du premier jour d'écriture au pilote, vingt-quatre semaines, dont les cinq premières ne coûtent que du temps et décident de tout le reste.
Semaines 0 à 2 : le cahier des charges. Une page de problème, cinq à huit parcours, la liste puis le tri, les écrans au crayon, un critère par fonction, la relecture à deux voix. Semaines 2 à 5 : trois devis. Le même document envoyé à trois prestataires, un entretien d'une heure avec chacun, les six questions par écrit ; le ramadan commence vers le 8 février 2027 et tombe sur cette période, ce qui ne gêne pas une consultation. Semaines 5 à 7 : le cadrage. Ateliers avec le prestataire retenu, prototype cliquable testé avec cinq utilisateurs, cahier des charges amendé, contrat signé avec la propriété écrite.
Semaines 7 à 17 : la version 1. Quatorze fonctions, une démonstration toutes les deux semaines sur un lien que vous ouvrez, les données existantes reprises dès la première démonstration et non à la fin. Semaines 17 à 20 : la recette et la mise en ligne. Chaque critère vérifié un à un, par vous et par un utilisateur ; publication sur Play puis App Store, Apple indiquant que 90 % des soumissions sont examinées en moins de 24 heures en moyenne, ce qui n'empêche pas un refus et une seconde soumission. Semaines 20 à 24 : le pilote. Dix utilisateurs réels, les retours notés, la décision sur la version 2 prise en juin, avant l'été. Les délais réels par type de projet sont détaillés dans le guide sur combien de temps prend une application ou une plateforme.
Ce qui fait échouer un cahier des charges
- Commencer par la liste des fonctions. Sans page de problème ni parcours, la liste grossit et personne ne peut la trier ; le devis chiffre quarante fonctions dont quatorze servent.
- Ne pas trier. Tout est « indispensable » ; le prestataire chiffre tout, le délai double, et la version 1 sort après que le marché a bougé.
- Écrire des adjectifs. « Moderne », « intuitif », « fluide », « sécurisé » : rien de vérifiable à la recette, et le désaccord arrive à la livraison.
- Imposer la technique. Le langage, le framework et l'hébergeur choisis par le demandeur retirent au prestataire la responsabilité du résultat et font monter le prix.
- Oublier les données existantes. L'Excel des tarifs, le logiciel comptable, la caisse : découverts au troisième mois, ils ajoutent un mois.
- Laisser la propriété pour plus tard. Les comptes au nom du prestataire, le dépôt chez lui ; la négociation commence le jour où il ne répond plus.
- Confondre cahier des charges et contrat. Le document dit quoi et pourquoi ; le contrat dit à quel prix, quand, à qui appartient quoi et ce qui se passe après. Il faut les deux.
Questions fréquentes
Les questions que nous recevons de dirigeants et de fondateurs à qui un prestataire a demandé « votre cahier des charges ».
- Faut-il vraiment un cahier des charges pour obtenir un devis ?
- Pour obtenir un prix, non ; pour obtenir un prix qui veut dire quelque chose, oui. Sans document, chaque prestataire chiffre le projet qu'il a imaginé, et les écarts entre devis mesurent cette imagination, pas le travail. Neuf pages écrites en deux semaines suffisent ; un prestataire sérieux vous les rendra relues et complétées avant de signer.
- Combien de pages, et faut-il un modèle ?
- Entre six et douze pages pour une première version d'application ou de plateforme ; au-delà, le document est en général une liste non triée. Les modèles téléchargés en ligne ont un défaut : ils font remplir des rubriques techniques que vous ne maîtrisez pas et sautent la page de problème et les parcours. Les six parties de ce guide suffisent de plan.
- Dois-je indiquer mon budget dans le cahier des charges ?
- Une fourchette, oui. Un budget caché n'obtient pas un meilleur prix ; il obtient trois devis construits sur trois hypothèses différentes. Une fourchette honnête permet au prestataire de proposer la version 1 qui y tient et de dire ce qui passe en version 2, et c'est précisément la discussion que vous voulez avoir avant de signer, pas après.
- Cahier des charges ou maquettes : par quoi commencer ?
- Le cahier des charges, court, puis les maquettes avec le prestataire retenu. Des maquettes faites avant la page de problème et le tri dessinent une application complète que personne n'a décidé de financer, et elles figent des choix d'écran avant que les parcours soient connus. Les écrans au crayon avec une capture de référence par écran suffisent au stade du devis.
- Le prestataire propose d'écrire le cahier des charges lui-même. Est-ce une bonne idée ?
- Il peut le compléter, pas le commencer. La page de problème, les parcours et le tri doivent venir de vous, parce qu'ils décident ce que vous paierez et ce que vous n'aurez pas. Un prestataire qui écrit le document de zéro écrit, de bonne foi, le projet qu'il sait construire. L'ordre qui marche : vous écrivez les neuf pages, il les relit, les complète pour les données et les contraintes, et vous rend les trois options et leur prix total avant de signer.
- Et si je change d'avis en cours de route ?
- Vous changerez d'avis, et le document est fait pour cela : la colonne « ensuite » existe pour accueillir ce qui apparaît pendant la construction sans toucher à la version 1. Une démonstration toutes les deux semaines sert précisément à décider tôt ; ce qui remplace une fonction de la version 1 en fait sortir une autre, à effort égal, et le prestataire le chiffre par écrit. Ce qui coûte cher, ce n'est pas de changer d'avis, c'est de le faire sans document pour mesurer le changement.