Sommaire — 3 sections
En informatique, le cahier des charges fait trois choses que les échanges de mail ne font jamais : il fixe un périmètre opposable, il force à distinguer le build du run, et il engage le fournisseur sur des niveaux de service mesurables. Sans lui, la négociation se rejoue à chaque lot : le prestataire facture les évolutions non prévues, et l’acheteur découvre que « maintenance » ne couvrait pas les mises à jour de sécurité.
À quoi sert ce cahier des charges
Le document ne décrit pas une application : il décrit une mission et la façon de juger qu’elle est réussie. Pour un développement, il borne le périmètre et les critères de recette. Pour un run, il définit les niveaux de service et les astreintes. Dans les deux cas, il transforme un besoin exprimé par un métier en une question à laquelle plusieurs fournisseurs peuvent répondre de façon comparable.
Les huit sections du modèle
L’ordre suit la lecture du fournisseur : le contexte d’abord, le tarif en dernier. Chaque section indique ce qu’on y écrit, avec un exemple pris dans une consultation de développement.
- 01
1. Contexte et système existant
Dix lignes sur l’application, son âge, sa criticité et ses dépendances. Exemple : « refonte du portail client (Spring Boot 3, Angular 16, PostgreSQL 15), 120 000 utilisateurs, indisponibilité maximale tolérée de deux heures par mois ».
- 02
2. Objet et nature de la prestation
Régie, forfait ou assistance technique, écrit noir sur blanc. En régie, veillez au risque de prêt de main-d’œuvre illicite (délit de marchandage) : cadrez le résultat attendu et l’encadrement. Exemple : « forfait pour la refonte du module de souscription, assistance technique pour le maintien en condition opérationnelle du socle existant ».
- 03
3. Périmètre fonctionnel et technique
Ce qui est dans la mission, ce qui n’y est pas. Exemple : « dans le périmètre : le parcours de souscription web ; hors périmètre : l’application mobile et l’interface d’administration ».
- 04
4. Environnement, accès et données
Accès aux environnements, données de test anonymisées, habilitations, confidentialité. Exemple : « accès au seul environnement de préproduction, données de production jamais consultables, chiffrement des postes ».
- 05
5. Compétences et séniorité
Séparez l’exigé de l’apprécié. Exemple : « exigé : cinq ans sur Spring Boot et PostgreSQL ; apprécié : une expérience Kubernetes en production ».
- 06
6. Niveaux de service et astreintes
Disponibilité attendue, délai de correction par sévérité, astreinte. Exemple : « disponibilité 99,5 %, correction sous quatre heures ouvrées pour une anomalie bloquante, astreinte le week-end lors des mises en production ».
- 07
7. Réversibilité et propriété du code
Dépôt livré, documentation, reprise par un tiers. Exemple : « le code source est versionné dans un dépôt de l’entreprise, les accès d’administration sont remis à la fin de la mission ».
- 08
8. Critères d’évaluation et modalités de réponse
Pondération annoncée avant la diffusion, date limite, pièces demandées. Exemple : « 35 % compétences, 30 % prix, 20 % références, 15 % disponibilité ; réponse attendue sous dix jours ouvrés ».
Les cinq erreurs fréquentes
Ce sont les cinq fautes que l’on retrouve dans les consultations qui dérivent, quelle que soit la taille de l’entreprise.
- Confondre régie et forfait. Un développement au forfait avec un périmètre flou reporte tout le risque sur le fournisseur, qui le reprend dans son prix. Une régie sans cadrage transfère tout le risque sur l’acheteur.
- Oublier la réversibilité. Sans dépôt livré ni documentation, la sortie du prestataire coûte plus cher que la mission elle-même, et l’application reste captive.
- Exiger douze technologies. Le dossier devient invérifiable et le panel se réduit aux deux fournisseurs qui cochent tout. Trois compétences exigées, quatre appréciées suffisent.
- Confondre TJM et coût. Un TJM bas sans périmètre de frais ni durée d’engagement est un coût caché. Comparez sur l’unité d’œuvre, pas sur le tarif affiché.
- Omettre les astreintes. Le jour où la production tombe un samedi, tout le monde découvre que « maintenance » ne couvrait pas le week-end.
Un cahier des charges informatique tient sur quatre à six pages : au-delà, plus personne ne le lit en entier, et les réponses portent sur les premières pages. Noralym génère ce document à partir du besoin et le diffuse aux fournisseurs.
Questions fréquentes
- Faut-il décrire la stack technique dans le cahier des charges ?
- Oui, mais comme un contexte, pas comme une liste d’exigences. Annoncez l’existant — langages, base de données, hébergement — pour que le fournisseur chiffre juste ; n’exigez la maîtrise que des briques réellement stratégiques, sinon le panel se réduit artificiellement.
- Quelle différence entre un TJM et un coût journalier complet ?
- Le TJM est le tarif affiché ; le coût complet ajoute les frais de déplacement, l’outillage, la garantie et la durée d’engagement. Deux fournisseurs au même TJM peuvent coûter très différemment une fois le périmètre de frais écrit.
- Combien de temps prévoir pour la réversibilité ?
- La réversibilité se prépare dès la première ligne du cahier des charges : dépôt du code, documentation, remise des accès. À la fin de la mission, un transfert non préparé peut prendre plusieurs semaines et immobiliser l’application.
Rédiger ce document sur votre besoin
Ce modèle est un point de départ. L’outil gratuit le rédige à partir de votre besoin, sans compte.