Modèle de cahier des charges informatique, à remplir.

Onze pages. Huit sections avec un exemple rempli à chacune, les clauses qui vous protègent déjà rédigées, et une grille pour lire les devis que vous recevrez. En Word, pour le remplir plutôt que le lire. Pas de formulaire, pas d'email à laisser.

Réutilisable librement, y compris commercialement. Aucune attribution exigée. Si vous l'améliorez pour votre secteur, gardez-le, c'est le but.

Ce qu'il y a dedans

Huit sections, et deux annexes.

Chaque section commence par un encadré qui explique ce qu'on attend dedans et pourquoi. Vous le supprimez avant d'envoyer le document.

1. 01

   Contexte et objectif

   Pourquoi ce projet existe maintenant. Le problème, pas la solution. Avec le déclencheur daté et ce qui est explicitement hors périmètre.

2. 02

   Les utilisateurs et ce qu'ils font

   Un tableau à remplir : profil, combien de personnes, ce qu'elles font dans l'outil, à quelle fréquence. Plus les contraintes de poste, qui changent la conception plus que n'importe quelle fonctionnalité.

3. 03

   Les processus, du début à la fin

   La section la plus utile, et celle qui est presque toujours bâclée. Deux cas réels déroulés entièrement, y compris le cas dégradé, qui est là où les logiciels mal cadrés se cassent.

4. 04

   Les connexions à l'existant

   Quels outils devront se parler, ce qui doit circuler, dans quel sens. Un outil qui ne communique pas recrée la double saisie que vous vouliez supprimer.

5. 05

   Les données à reprendre

   Volume, emplacement, qualité connue, et ce que vous acceptez de ne pas reprendre. C'est la section absente qui fait déraper les budgets.

6. 06

   Les contraintes non fonctionnelles

   Disponibilité, volumétrie à trois ans, hébergement, sécurité, données personnelles, accessibilité, sauvegarde. Sept lignes qui coûtent souvent plus cher que les fonctionnalités.

7. 07

   Les critères de recette

   Comment on saura que c'est livré. Sans cette section, la fin du projet est une négociation. Avec elle, c'est un constat.

8. 08

   Le cadre du projet

   Échéance et ce qui la contraint, référent interne, format d'engagement, propriété du code, réversibilité, maintenance.

Questions fréquentes

Six réponses sans détour.

• Le modèle est-il vraiment gratuit et sans inscription ?

  Oui, les trois fichiers se téléchargent directement, sans formulaire et sans adresse email à laisser. Échanger un document contre un contact est la norme du marché, et c'est exactement pour cette raison qu'on ne le fait pas : le reste du site explique qu'on ne crée pas de dépendance, ce serait incohérent de commencer par là. Le modèle est réutilisable librement, y compris commercialement, et aucune attribution n'est exigée.

• En quoi ce modèle diffère des autres qu'on trouve en ligne ?

  Sur trois points concrets. Il contient les clauses qui protègent, formulées prêtes à copier : engagement sur la non-perte de données lors d'une migration, propriété du code source à la livraison, réversibilité documentée. La plupart des modèles disponibles les omettent, et ce sont précisément les lignes qu'on regrette de ne pas avoir écrites. Il contient aussi une annexe sur ce qu'il ne faut PAS mettre dedans, parce que quatre erreurs de rédaction coûtent plus cher que dix oublis. Et il est en Word, pas en PDF : un modèle qu'on ne peut pas remplir ne sert à rien.

• Quelle longueur doit faire un cahier des charges ?

  Dix à vingt pages pour un projet de PME. Au-delà, il n'est plus lu, ni par les prestataires qui vous répondent, ni par vous six mois plus tard quand il faut arbitrer. Un document de soixante pages n'est pas plus rigoureux, il est simplement plus difficile à opposer à qui ne l'a pas respecté. Si une section ne vous concerne pas, écrivez « sans objet » : une section vide fait douter, une section explicitement écartée rassure.

• Faut-il choisir la technologie dans le cahier des charges ?

  Non, 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 ou un socle sans cette raison revient à écarter des solutions meilleures sans le savoir, et à priver les prestataires de la partie de leur travail où ils apportent le plus. Décrivez le problème et les contraintes ; laissez-les proposer le moyen.

• Peut-on faire relire son cahier des charges avant de consulter ?

  C'est même la chose la plus rentable à faire. Un cahier des charges écrit sans regard technique décrit fidèlement le problème et se trompe souvent sur ce qui est coûteux : une exigence anodine peut doubler la charge, une exigence qui paraît lourde peut être gratuite. 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 par quelqu'un qui construit ce genre de système et n'a aucun intérêt dans le marché, ou mener un cadrage court avant de consulter.

• Ce modèle convient-il à un marché public ?

  Il en couvre le fond technique, mais pas la forme réglementaire. Un dossier de consultation public s'accompagne de pièces qui lui sont propres, avec un formalisme et des délais imposés. Servez-vous de ce modèle pour construire le contenu, puis faites-le entrer dans le cadre réglementaire applicable à votre situation, plutôt que l'inverse.