Aller au contenu

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. Pas de formulaire, pas d'adresse à 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.

Page 1 du modèle : la couverture
La couverture du document, telle que vous l’ouvrirez.

Trois pages de plus, telles quelles.

Pas une maquette : les pages du document que vous allez ouvrir.

  • Page 3 du modèle : une section, avec ses exemples remplis et son contre-exemple
    03Une section, avec ses exemples remplis et son contre-exemple
  • Page 9 du modèle : les clauses à copier, prêtes à coller dans votre document
    09Les clauses à copier, prêtes à coller dans votre document
  • Page 10 du modèle : la grille de lecture des devis reçus
    10La grille de lecture des devis reçus

Trois clauses qui vous protègent, et que la plupart des modèles oublient.

Ce sont les lignes qu'on regrette de ne pas avoir écrites. Elles sont fournies déjà formulées, prêtes à copier.

  • La non-perte de données

    Une migration se passe presque toujours bien. « Presque » est le mot qui coûte cher. Le modèle contient l'engagement à faire porter par le prestataire, restauration à sa charge comprise.

  • La propriété du code source

    Beaucoup de contrats accordent un droit d'usage, pas la propriété. La nuance ne se voit qu'au moment de changer de prestataire, c'est-à-dire au pire moment. La clause est écrite.

  • La réversibilité

    Documentation d'exploitation, une personne formée chez vous, passation documentée si la collaboration s'arrête. Un prestataire qui accepte cette ligne s'engage ; un prestataire qui l'évite vous renseigne.

Ce que vous remplirez, section par section.

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

  1. 01Contexte et objectifPourquoi 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. 02Les utilisateurs et ce qu'ils fontQui, combien, ce qu'ils font dans l'outil et à quelle fréquence. Plus les contraintes de poste, qui changent la conception plus que n'importe quelle fonctionnalité.
  3. 03Les processus, du début à la finDeux cas réels déroulés entièrement, y compris le cas dégradé : c’est là que les logiciels mal cadrés se cassent.
  4. 04Les connexions à l'existantQuels outils devront se parler, ce qui circule, dans quel sens. Un outil isolé recrée la double saisie que vous vouliez supprimer.
  5. 05Les données à reprendreVolume, emplacement, qualité connue, et ce que vous acceptez de ne pas reprendre : la section absente qui fait déraper les budgets.
  6. 06Les contraintes non fonctionnellesDisponibilité, volumétrie à trois ans, hébergement, sécurité, données personnelles, accessibilité, sauvegarde.
  7. 07Les critères de recetteComment on saura que c'est livré. Sans cette section, la fin du projet est une négociation ; avec elle, un constat.
  8. 08Le cadre du projetÉchéance, référent interne, format d'engagement, propriété du code, réversibilité, maintenance.

Plus deux annexes : ce qu'il ne faut pas mettre dedans (quatre erreurs de rédaction qui coûtent plus cher que dix oublis, dont les maquettes d'écrans et la liste de fonctionnalités sans priorité), et le point aveugle d'un cahier des charges écrit seul.

Vous voulez autre chose que le fichier ?

Longueur, technologie, marché public : vos questions.

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. Le modèle est réutilisable librement, y compris commercialement, et aucune attribution n'est exigée.

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

Il contient les clauses qui protègent, prêtes à copier :

  • non-perte de données lors d'une migration
  • propriété du code source à la livraison
  • réversibilité documentée

Il contient aussi une annexe sur ce qu'il ne faut pas mettre dedans. Et il est en Word, pour être rempli.

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, ni par vous six mois plus tard. Si une section ne vous concerne pas, écrivez « sans objet » : une section vide fait douter, une section écartée rassure.

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

Non, sauf contrainte réelle : une équipe interne qui reprendra le code, une brique imposée par votre groupe. Décrivez le problème et les contraintes, et laissez les prestataires proposer le moyen.

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

C'est même la chose la plus rentable à faire. Écrit sans regard technique, un cahier des charges décrit fidèlement le problème et se trompe souvent sur ce qui coûte cher.

Faites-le relire par quelqu'un qui construit ce genre de système et n'a aucun intérêt dans le marché, ou menez un cadrage court avant de consulter.

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

Il en couvre le fond technique, pas la forme réglementaire. Servez-vous-en pour construire le contenu, puis faites-le entrer dans le cadre réglementaire qui s'applique à votre consultation.

Une relecture avant de consulter vaut mieux qu'un avenant après.

Vous avez rempli le modèle et voulez un regard technique avant de l'envoyer ? 20 minutes, sans proposition commerciale au bout.

Parler de mon projet

Réponse sous 48 heures

L'assistance à maîtrise d'ouvrage