## Mode d'emploi, en soixante secondes **Ce document sert deux fois.** La première pour obtenir des devis comparables. La seconde, six mois plus tard, pour opposer à un prestataire ce qui avait été convenu. C'est ce second usage qui décide de sa forme : chaque phrase doit pouvoir être déclarée tenue ou non tenue. **Comment le remplir.** Remplacez ce qui est entre crochets. Les blocs *Exemple* vous montrent le niveau de précision attendu, ils sont là pour être imités puis supprimés. Les blocs *À copier* contiennent des formulations juridiques prêtes à l'emploi, à garder telles quelles. **Combien de temps.** Comptez une demi-journée si vous connaissez votre sujet, deux ateliers d'une heure avec vos équipes sinon. Un cahier des charges qui prend trois semaines est un cahier des charges qu'on a confondu avec un projet. **Quelle longueur.** Dix à vingt pages. Au-delà, il n'est plus lu, ni par les prestataires qui répondent, ni par vous quand il faudra arbitrer. Un document de soixante pages n'est pas plus rigoureux : il est plus difficile à opposer. > **La règle qui vaut tout le reste.** Si une section ne vous concerne pas, écrivez « sans objet » plutôt que de la laisser vide. Une section vide fait douter de votre sérieux et sera chiffrée au plus prudent. Une section explicitement écartée rassure et fait baisser le prix. --- ## Fiche projet | | | |---|---| | **Projet** | [nom court, celui que tout le monde utilisera] | | **Entité** | [raison sociale] | | **Rédigé par** | [nom, fonction] | | **Décideur** | [nom, fonction, celui qui signe] | | **Référent opérationnel** | [nom, fonction, celui qui répondra aux questions] | | **Date** | [date] | | **Version** | 1.0 | | **Réponse attendue avant le** | [date] | --- # 1. Le problème, pas la solution **Ce qu'on attend ici.** Pourquoi ce projet existe maintenant. Un prestataire qui comprend le problème peut proposer mieux que ce que vous aviez imaginé. Un prestataire qui ne lit qu'une liste de fonctions se contente de chiffrer la liste. **La situation aujourd'hui.** [Qui fait quoi, avec quel outil, combien de fois par semaine, en combien de temps.] > **Exemple.** Quatre commerciaux produisent chacun huit à douze devis par semaine. Chaque devis demande de rechercher les tarifs dans un classeur Excel de 2019, de vérifier la disponibilité par téléphone à l'atelier, puis de ressaisir les lignes dans le logiciel de facturation. Comptage fait sur deux semaines en mars : quarante minutes par devis, dont vingt-cinq de recherche et de ressaisie. **Le déclencheur, daté.** [Ce qui fait que le sujet arrive maintenant et pas l'an dernier.] > **Exemple.** Le responsable qui maintenait le classeur est parti en janvier. Depuis, deux erreurs de tarif sont passées en clientèle, dont une à 4 000 euros de marge perdue. **Le résultat attendu, mesurable.** [Ce que vous voulez obtenir, exprimé de façon vérifiable.] > **Exemple.** Ramener la production d'un devis sous dix minutes, et supprimer la ressaisie vers la facturation. Objectif tenu si un commercial produit trois devis réels chronométrés en moins de dix minutes chacun. > **Contre-exemple, à ne pas écrire.** « Moderniser nos outils et gagner en efficacité. » Ce n'est pas un objectif, c'est une intention. Elle ne peut être ni chiffrée ni déclarée atteinte. **Ce qui est hors périmètre.** [Aussi important que le reste : ce que le projet ne traitera pas.] > **Exemple.** La comptabilité générale, la paie et le site web ne sont pas dans le périmètre. La gestion des stocks est hors périmètre pour cette phase, à réexaminer en 2027. --- # 2. Qui s'en sert, et pour quoi faire **Ce qu'on attend ici.** Un logiciel utilisé par trois personnes du même service et un logiciel utilisé par quarante personnes de cinq métiers ne se construisent pas de la même façon. | Profil | Nombre | Ce qu'il fait dans l'outil | Fréquence | |---|---|---|---| | [ex. commercial] | [4] | [crée un devis, suit ses relances] | [plusieurs fois par jour] | | [ex. atelier] | [12] | [déclare l'avancement d'un ordre] | [quotidien] | | [ex. direction] | [1] | [consulte le tableau de bord] | [hebdomadaire] | | | | | | **Contraintes de poste.** [Mobile, gants, hors réseau, poste partagé, écran de faible résolution.] > **Exemple.** Les douze opérateurs d'atelier travaillent avec des gants, sur une tablette fixée au poste, dans un bâtiment où le réseau sans fil tombe plusieurs fois par jour. L'outil doit rester utilisable hors connexion et resynchroniser sans intervention. > **Pourquoi cette section pèse lourd.** Ces contraintes changent la conception plus que n'importe quelle fonctionnalité. Découvertes en recette, elles se paient en avenant. Écrites ici, elles sont dans le prix. --- # 3. Les processus, du début à la fin **Ce qu'on attend ici.** Le déroulé complet d'au moins deux cas réels, du premier geste au dernier. C'est la section la plus utile du document et celle qui est presque toujours bâclée. Décrire des écrans produit un logiciel qui ressemble à ce que vous avez imaginé. Décrire un processus produit un logiciel qui marche. **Processus 1 : [nom, ex. « de la demande client à la facture »]** 1. [Qui fait quoi, avec quelle information en entrée] 2. [Étape suivante, et ce qui déclenche le passage] 3. [...] **Et quand ça ne se passe pas comme prévu :** [Le cas dégradé.] > **Exemple, cas nominal.** 1. Le commercial reçoit une demande par téléphone ou par courriel. 2. Il identifie le client dans la base, ou le crée. 3. Il compose les lignes du devis à partir du catalogue tarifaire. 4. Si le montant dépasse 15 000 euros, la direction valide avant envoi. 5. Le devis part au client en PDF. 6. À l'acceptation, il devient une commande sans ressaisie. 7. La facturation reprend les lignes de la commande. > > **Exemple, cas dégradés.** Le client demande une remise supérieure au seuil autorisé : le devis part en validation, et le commercial doit pouvoir suivre où en est sa demande. Un article n'est plus au catalogue : la ligne doit rester saisissable en texte libre avec un prix manuel, sinon les commerciaux retourneront à Excel. La validation n'arrive pas avant trois jours : le devis doit remonter dans une liste d'attente visible. **Processus 2 : [nom]** 1. [...] > **Le test de cette section.** Donnez-la à quelqu'un qui ne connaît pas votre métier et demandez-lui de raconter le processus à voix haute. S'il y arrive, elle est bonne. S'il pose trois questions, ces trois questions sont exactement ce qu'un prestataire chiffrera au plus cher. --- # 4. Les connexions à l'existant **Ce qu'on attend ici.** Un outil qui ne communique pas avec les autres recrée la double saisie, c'est-à-dire exactement le problème que vous vouliez résoudre. | Outil existant | Éditeur et version | Ce qui doit circuler | Sens | Interface connue | |---|---|---|---|---| | [compta] | [nom, version] | [factures validées] | [sortant] | [API / export / inconnu] | | [CRM] | [nom] | [fiches clients] | [les deux sens] | [à instruire] | | | | | | | > **Exemple.** Logiciel de facturation Sage 100c version 2021, hébergé sur un serveur interne. Les commandes validées doivent y créer une facture brouillon. Existence d'une API non vérifiée à ce jour : à instruire pendant le cadrage. Un export en fichier plat est possible en dernier recours, mais il ne conviendra pas, parce qu'il suppose une action humaine quotidienne. > **Si vous ne savez pas, écrivez-le.** « Interface à instruire » est une information utile et honnête. Cocher « API disponible » au hasard produit un devis faux, et la correction se fera à votre charge. --- # 5. Les données à reprendre **Ce qu'on attend ici.** Ce qui doit être récupéré de l'ancien système, et dans quel état il se trouve. C'est la section absente qui fait déraper les budgets. | Données | Volume | Où elles sont | Qualité connue | Reprise | |---|---|---|---|---| | [clients] | [3 500 fiches] | [Excel + ancien logiciel] | [doublons connus] | [oui] | | [historique commandes] | [8 ans] | [base ancien outil] | [complète] | [3 ans seulement] | | | | | | | > **Exemple.** 3 500 fiches clients réparties entre le classeur Excel et le logiciel de facturation, avec un recouvrement partiel et des doublons dus aux variantes d'orthographe. Huit ans d'historique de commandes disponibles ; les commerciaux ne consultent en pratique que les trois dernières années. Décision prise : reprise de trois ans dans le nouvel outil, archivage du reste en lecture seule. **Ce qu'on accepte de ne pas reprendre.** [La décision la plus rentable du chantier, à prendre avant et non pendant.] > **À copier, exigence de non-perte.** « Le prestataire s'engage contractuellement sur la non-perte de données lors de la reprise. En cas de perte imputable à son intervention, la restauration est à sa charge et sans délai facturable. Une migration à blanc complète est réalisée avant la bascule, suivie d'un contrôle en deux passes : automatique sur les volumes et les totaux, manuel sur un échantillon tiré au hasard par le client. » --- # 6. Les contraintes qui décident de la solution **Ce qu'on attend ici.** Tout ce qui n'est pas une fonctionnalité mais qui détermine la solution technique. Ces lignes coûtent souvent plus cher que les fonctionnalités, et elles ne sont jamais chiffrées si elles ne sont pas écrites. | Contrainte | Votre réponse | Exemple de réponse utile | |---|---|---| | **Disponibilité** | [ ] | Utilisable de 7h à 20h en semaine. Une heure d'arrêt en journée bloque l'atelier. | | **Volumétrie à trois ans** | [ ] | 3 500 clients, 12 000 devis par an, croissance de 20 % par an. | | **Hébergement** | [ ] | Cloud accepté, données en Union européenne, hébergement chez nous non exigé. | | **Authentification** | [ ] | Réutiliser l'annuaire existant. Droits par profil : commercial, atelier, direction. | | **Traçabilité** | [ ] | Savoir qui a modifié un prix, et quand. | | **Données personnelles** | [ ] | Données clients professionnels uniquement. Conservation trois ans après le dernier contact. | | **Accessibilité** | [ ] | Obligation à vérifier selon notre statut, pas à supposer. | | **Sauvegarde et reprise** | [ ] | Sauvegarde quotidienne, restauration testée par le prestataire une fois avant la réception. | > **La ligne la plus souvent oubliée.** « Restauration testée » et « sauvegarde configurée » ne sont pas la même exigence. Une sauvegarde qui n'a jamais été restaurée n'est pas une sauvegarde, c'est une hypothèse. Exigez le test, une fois, avant de prononcer la réception. --- # 7. Les critères de recette **Ce qu'on attend ici.** Comment on saura que c'est livré. Sans cette section, la fin du projet est une négociation. Avec elle, c'est un constat. Un critère utile est une phrase qu'on peut déclarer vraie ou fausse sans discuter. | # | Critère | Comment on le vérifie | Bloquant | |---|---|---|---| | 1 | [ ] | [ ] | [oui/non] | | 2 | [ ] | [ ] | | | 3 | [ ] | [ ] | | > **Exemples de critères qui tiennent.** 1. Un commercial produit un devis complet de cinq lignes en moins de dix minutes, chronométré sur trois devis réels tirés au hasard. Bloquant. 2. Une commande validée crée une facture brouillon dans Sage sans aucune ressaisie, vérifié sur une journée d'activité réelle. Bloquant. 3. Un opérateur d'atelier déclare un avancement avec des gants, sur tablette, réseau coupé, et la donnée remonte à la reconnexion. Bloquant. 4. Le tableau de bord de direction s'affiche en moins de trois secondes avec les données de l'année. Non bloquant. > **Contre-exemples, à ne jamais écrire.** « L'outil est ergonomique. » « Les performances sont satisfaisantes. » « L'interface est moderne. » Aucune de ces phrases ne peut être déclarée fausse, donc aucune ne vous protège. **Qui prononce la recette.** [Une personne nommée. Une recette « validée par l'équipe » n'est jamais prononcée.] --- # 8. Le cadre du projet **Ce qu'on attend ici.** Les conditions autour de la réalisation. Un prestataire qui accepte ces lignes s'engage ; un prestataire qui les évite vous renseigne. **Échéance, et ce qui la contraint.** [La date, et pourquoi elle existe.] > **Exemple.** Mise en service souhaitée avant le 15 septembre, parce que la période de forte activité commence en octobre et qu'aucune bascule ne sera possible ensuite avant janvier. Cette contrainte est réelle et non négociable. **Disponibilité de notre côté.** [Le référent, et le temps réellement réservé.] > **Exemple.** Le référent opérationnel dispose d'une demi-journée par semaine, réservée dans son planning. En son absence, la direction technique tranche. Les arbitrages sont rendus en cinq jours ouvrés maximum. > **Pourquoi ça figure dans un cahier des charges.** C'est le meilleur prédicteur de dérapage qui existe. Un projet sans référent interne disponible glisse quel que soit le prestataire, et le prestataire le sait : s'il ne voit pas cette ligne, il ajoutera une marge de sécurité que vous paierez. **Format d'engagement attendu.** [Forfait sur périmètre défini, ou temps passé plafonné.] > **À copier, engagement de résultat.** « La prestation est réalisée au forfait sur le périmètre défini au présent cahier des charges. Le prestataire s'engage sur les livrables, les délais et les critères de recette. En cas de manquement, les contreparties sont celles prévues au contrat, à sa charge. » > **À copier, propriété des livrables.** « À la livraison et au paiement intégral, le client devient propriétaire du code source produit pour son projet, des contenus rédigés, de la documentation technique, des scripts de déploiement et des accès aux outils tiers ouverts pour le projet. Le prestataire garantit que les livrables ne portent pas atteinte aux droits de tiers. » > **À copier, réversibilité.** « Le prestataire fournit une documentation d'exploitation permettant à un tiers de reprendre la maintenance, et forme au moins une personne désignée par le client. Cette documentation est relue par une personne ne l'ayant pas rédigée, qui exécute au moins une procédure en la suivant. En cas d'interruption de la collaboration, une passation documentée est fournie dans un délai de [15] jours. » **Maintenance après livraison.** [Ce que vous attendez, et pour combien de temps. Précisez si un contrat récurrent est souhaité ou explicitement refusé.] --- # Annexe A. Ce qu'il ne faut pas mettre dedans Quatre erreurs qui coûtent cher, et qu'on retrouve dans la majorité des cahiers des charges reçus. **1. Des maquettes d'écrans.** Elles verrouillent la conception avant que quiconque ait compris le processus, et elles privent les prestataires de la partie de leur travail où ils apportent le plus. Décrivez ce que la personne doit accomplir, pas où doit se trouver le bouton. **2. Un choix de technologie.** Sauf contrainte réelle, par exemple une équipe interne qui devra reprendre le code ou une brique imposée par votre groupe, imposer un langage revient à écarter des solutions meilleures sans le savoir. Écrivez la contrainte, pas la conclusion. **3. Une liste de fonctionnalités sans priorité.** Tout est indispensable, donc rien ne l'est, et le devis se calcule sur le tout. Classez en trois niveaux : | Niveau | Signification | Effet sur le devis | |---|---|---| | **Vital** | Sans cela, le projet ne sert à rien | Chiffré et engagé | | **Utile** | Attendu à la mise en service | Chiffré, arbitrable si le budget serre | | **Plus tard** | Souhaitable, pas maintenant | Hors périmètre, cité pour l'architecture | **4. Un budget dissimulé.** Cacher l'enveloppe pour « voir les prix » fait perdre du temps aux deux parties et attire les propositions qui promettent tout. Donner une fourchette permet de calibrer une réponse honnête, et de disqualifier immédiatement celui qui répond exactement le montant annoncé. --- # Annexe B. Grille de lecture des devis reçus C'est ici que ce document sert la seconde fois. Reportez les réponses de chaque candidat : les écarts sautent aux yeux. | Point à vérifier | Candidat A | Candidat B | Candidat C | |---|---|---|---| | **La reprise de données a-t-elle sa propre ligne, avec sa propre durée ?** | | | | | **La recette est-elle chiffrée, et le temps client est-il mentionné ?** | | | | | **La formation des utilisateurs est-elle incluse ou exclue ?** | | | | | **Le mot « cession » figure-t-il, et pas seulement « droit d'usage » ?** | | | | | **L'engagement de non-perte de données est-il accepté ?** | | | | | **La réversibilité est-elle décrite avec un délai ?** | | | | | **Les cas dégradés du §3 sont-ils traités dans la réponse ?** | | | | | **Qui écrit le code, nommément, et le rencontrerez-vous ?** | | | | | **Que couvre la garantie après mise en service, et pendant combien de temps ?** | | | | | **Qu'est-ce qui est explicitement exclu du devis ?** | | | | > **Comment se servir de cette grille.** Ne comparez pas les montants avant d'avoir rempli les dix lignes. Un écart de prix important entre deux devis ne vient presque jamais du tarif : il vient de ce que l'un a inclus et l'autre pas. Le devis le moins cher est fréquemment celui qui a le moins compris, et c'est celui qu'on choisit. --- # Annexe C. Les sept questions à poser à l'oral À poser avant de signer, dans cet ordre. Les réponses se classent d'elles-mêmes, et aucune ne s'improvise. **1. « Qu'est-ce qui a dérapé sur votre dernier projet, et qui l'a payé ? »** Écoutez surtout la seconde partie. « Le client a validé un avenant » et « on a absorbé la charge » décrivent deux modèles économiques, et vous serez traité selon celui-là. **2. « Si dans deux ans je confie les évolutions à une autre équipe, que me remettez-vous, et en combien de temps ? »** Une réponse organisée existe : le dépôt, la documentation d'exploitation, les accès, une passation de quelques jours. Un prestataire que la question met mal à l'aise vient de vous donner l'information la plus utile du rendez-vous. **3. « Qui va écrire le code, concrètement, et est-ce que je le rencontrerai ? »** Un profil senior au rendez-vous commercial et un profil junior à la réalisation n'est pas illégitime. Le savoir avant de signer, oui. **4. « Comment gérez-vous la reprise de nos données ? »** Une bonne réponse contient des questions. Une réponse qui traite le sujet comme un import de fichier est le signal le plus fiable d'un devis qui va glisser. **5. « Qu'est-ce qui n'est pas dans ce devis ? »** Posée à l'envers de l'habitude. Un prestataire qui énonce spontanément ses exclusions vous fait gagner l'argument que vous auriez eu six mois plus tard. **6. « Sur quoi vous engagez-vous, et que se passe-t-il si vous ne le tenez pas ? »** Trois réponses possibles : engagement de moyens, ce qui met le risque chez vous ; engagement de résultat sans contrepartie, ce qui est une formule ; engagement de résultat avec contreparties écrites, ce qui est un engagement. **7. « Que feriez-vous si nous n'avions pas de budget pour ce projet ? »** La plus révélatrice. Une réponse utile existe presque toujours : une version réduite, un outil du marché acceptable, un problème adjacent moins coûteux. Un prestataire qui répond que le projet est indispensable vient de dire ce qui l'intéresse. --- # Annexe D. Le point aveugle d'un cahier des charges écrit seul Un cahier des charges rédigé sans regard technique décrit fidèlement le problème et se trompe presque toujours sur ce qui est coûteux. Une exigence qui paraît anodine peut doubler la charge ; une exigence qui paraît lourde peut être gratuite parce que l'outil la fournit déjà. Ce n'est pas un défaut de rédaction, c'est une asymétrie d'information normale. Deux façons de la corriger. **Faire relire le document** par quelqu'un qui construit ce genre de système et qui ne concourra pas au marché. Une demi-journée de relecture déplace souvent plus de valeur que trois semaines de rédaction supplémentaire. **Mener un cadrage court avant de consulter**, avec quelqu'un qui ouvre le capot, regarde l'état réel des données et liste les vraies connexions. Le livrable est ce document, rempli avec les bonnes réponses.