Rédiger un cahier des charges informatique qui protège l’acheteur
Un cahier des charges informatique ne sert pas seulement à obtenir des offres. C'est le document que l'on relit quand le projet tourne mal. Voici comment l'écrire pour qu'il protège celui qui achète.
L’erreur la plus courante tient en une phrase : le document décrit la solution que l’acheteur imagine, et non le problème qu’il veut résoudre. « Une application web en Java avec une base Oracle et un module de reporting. » Le prestataire retenu livre exactement cela. Le service n’en est pas mieux rendu, et l’acheteur n’a rien sur quoi s’appuyer pour réclamer. Un cahier des charges informatique sert à obtenir des offres comparables ; il sert surtout, des mois plus tard, à trancher un désaccord. C’est pour ce second usage qu’il faut l’écrire.
Ce guide passe en revue les parties du document qui protègent l’acheteur, et la manière de les rédiger pour qu’elles tiennent face à une livraison incomplète, un retard ou un changement de prestataire.
Partir des résultats, pas des moyens
La première partie décrit la situation actuelle et ce qui doit changer. Elle répond à des questions simples : qui utilise le service, combien de fois, pour faire quoi, avec quelles difficultés aujourd’hui. Puis : à quoi verra-t-on que le projet a réussi ? Un délai de traitement divisé, des dossiers retrouvés en quelques secondes, une démarche disponible en ligne de bout en bout.
Ces résultats ne fixent pas l’outil. Ils fixent ce que l’outil doit permettre, et ils deviennent la référence de la recette. Les contraintes réelles s’ajoutent ensuite : lieu d’hébergement imposé, langues, règles de sécurité de l’organisation, logiciels existants avec lesquels il faut échanger, connectivité des sites. Elles sont des exigences, pas des préférences, et il faut les présenter comme telles.
Une consultation préalable du marché aide à calibrer cette partie : elle montre ce qui existe, ce qui coûte cher et ce qui est irréaliste. Nous en avons décrit la méthode dans notre article sur le sourcing avant rédaction.
Rendre chaque exigence vérifiable
Une exigence qui ne peut pas être contrôlée ne protège personne. « Le système doit être performant » ne permet ni de comparer les offres ni de refuser une livraison. La règle pratique : chaque exigence importante comporte un critère, une mesure et le moment où elle sera vérifiée.
| Formulation vague | Formulation vérifiable |
|---|---|
| Le système doit être rapide. | La recherche d’un dossier par numéro renvoie un résultat en moins de deux secondes pour 95 % des requêtes, avec 200 utilisateurs connectés, mesuré lors de la recette. |
| L’application doit être accessible. | Les écrans destinés au public respectent le niveau AA des WCAG 2.2 ; un audit indépendant est remis avant la mise en service. |
| Les données doivent être sécurisées. | Les données sont chiffrées en transit et au repos ; les accès d’administration passent par une authentification à plusieurs facteurs et sont journalisés pendant un an. |
| Le prestataire assure la formation. | Le prestataire forme 15 référents en trois sessions et remet des supports modifiables ; les référents réalisent seuls les cinq opérations courantes à l’issue. |
| La solution doit être évolutive. | L’ajout d’un nouveau type de demande se fait par paramétrage, sans développement, et la procédure est documentée. |
Les chiffres de ce tableau sont des exemples. Ils doivent venir de l’usage réel : nombre d’utilisateurs simultanés observé, volumes annuels, pics saisonniers. Une exigence trop élevée renchérit les offres sans bénéfice ; une exigence trop basse ne protège pas.
Écrire ce qui appartient à l’acheteur
C’est la partie la plus souvent absente, et celle qui coûte le plus cher quand elle manque. Elle tient en quatre points.
Les données
Les données saisies, importées ou produites par le système appartiennent à l’acheteur, y compris les journaux et les paramétrages. Le prestataire ne peut pas les utiliser à d’autres fins. Si des données personnelles sont traitées, le contrat de sous-traitance prévu par le RGPD en fixe les conditions ; le cahier des charges doit déjà indiquer le lieu de traitement attendu et les sous-traitants autorisés.
Les livrables et le code
Pour un développement spécifique, préciser si l’acheteur obtient la propriété du code ou un droit d’usage, de modification et de transmission à un tiers. Pour un logiciel du marché, préciser au moins ce qui est développé en plus (connecteurs, écrans, scripts) et à qui cela revient.
La documentation
Documentation d’exploitation, d’administration, description des interfaces, modèle de données : la lister, avec le niveau de détail attendu et le moment de sa remise. Une documentation non livrée est l’une des causes les plus fréquentes de dépendance à un éditeur.
La réversibilité
Prévoir dès l’origine la sortie : contenu restitué, formats ouverts et documentés, délai, coût, durée de l’assistance au successeur. La clause se négocie mal en fin de contrat ; elle se négocie bien avant la signature.
Une clause de réversibilité qui se contente d’un « export des données sur demande » ne vaut presque rien. Sans format, sans délai et sans description du contenu, l’export peut être un fichier illisible remis trois mois plus tard.
Lier le paiement à une recette réelle
La recette est le moment où l’acheteur accepte la livraison. Elle doit être préparée dans le cahier des charges, pas improvisée à la fin. Concrètement : une liste de cas d’usage écrits à l’avance, avec les données de test et le résultat attendu ; une période de vérification en conditions proches du réel ; une classification des anomalies (bloquante, majeure, mineure) et la règle qui en découle, par exemple aucune anomalie bloquante et un nombre limité de majeures pour prononcer la réception.
Les paiements suivent les étapes de recette, pas le calendrier. Une part significative du prix réservée jusqu’à la vérification en service régulier est un levier simple et efficace.
Fixer le service après la mise en route
Le cahier des charges décrit aussi la vie du système : support (horaires, langues, canaux), délais de prise en charge et de résolution selon la gravité, disponibilité attendue et manière de la mesurer, maintenance corrective et évolutive, mises à jour de sécurité, durée de support annoncée. Les pénalités doivent être proportionnées et réellement applicables ; celles que personne n’ose appliquer ne protègent pas. Notre article sur les niveaux de service détaille comment les choisir.
Organiser la comparaison des offres
Les critères de choix et leur pondération sont annoncés dans le dossier. Ils reprennent les exigences importantes : un candidat qui ne peut pas démontrer la réversibilité ou la conformité d’accessibilité ne doit pas pouvoir compenser par un prix bas. Demander une démonstration sur les cas d’usage de la recette, plutôt qu’une présentation commerciale, rend les offres comparables. Le prix est évalué sur la durée totale : licences ou abonnements, intégration, hébergement, support, réversibilité.
Relire avant de publier
- Le besoin est décrit en résultats observables, sans imposer de solution technique injustifiée.
- Chaque exigence importante a un critère, une mesure et un moment de contrôle.
- La propriété des données, des développements et des journaux est écrite.
- La documentation due est listée, avec sa date de remise.
- La réversibilité précise le contenu, les formats, le délai, le coût et l’assistance.
- La recette repose sur des cas d’usage écrits et des seuils d’anomalies.
- Les paiements sont liés aux étapes de recette.
- Les niveaux de service sont mesurables et leurs pénalités applicables.
- Les critères de choix et leur pondération reprennent les exigences essentielles.
Un regard extérieur et sans intérêt commercial aide souvent à repérer ce qui manque. C’est le principe de notre expertise de conseil indépendant : relire le dossier du côté de l’acheteur, avant que les offres n’arrivent. Pour le cadre d’ensemble, notre dossier sur l’achat numérique dans le secteur public replace le cahier des charges dans la procédure.
Questions fréquentes
Faut-il décrire la solution technique dans un cahier des charges ?
En général non. Décrire la solution enferme l'acheteur dans une architecture qu'il n'a pas toujours les moyens de juger, et réduit la concurrence. Il vaut mieux décrire le besoin, les contraintes réelles (hébergement, sécurité, interopérabilité, langues) et les résultats attendus, puis laisser les candidats proposer et justifier leur solution.
Qu'est-ce qu'une clause de réversibilité ?
C'est l'engagement du prestataire à restituer les données, la documentation et, selon les cas, le code ou les paramétrages, dans des formats exploitables et dans un délai fixé, et à assister le passage vers un autre prestataire. Elle doit préciser le contenu restitué, les formats, le délai, le coût et la durée d'assistance.
Combien de temps faut-il pour rédiger un bon cahier des charges ?
Pour un projet informatique d'une certaine taille, plusieurs semaines sont courantes, consultation des utilisateurs et sourcing compris. Le temps passé à décrire le besoin et les critères de recette est généralement bien inférieur à celui que coûte un litige ou un projet à reprendre.
Le cahier des charges est-il le même dans le public et le privé ?
Les principes de rédaction sont les mêmes. Dans le secteur public, les règles de la commande publique ajoutent des contraintes de forme, d'égalité de traitement et de publicité ; le cahier des clauses techniques particulières y joue le rôle du cahier des charges.