Définition · Expression du besoin et cahier des charges
Cahier des charges technique : définition et contenu
En bref
Le cahier des charges technique précise les exigences techniques que la solution doit respecter : environnement existant, hébergement, intégrations, sécurité, performances, normes et réversibilité. Il complète le cahier des charges fonctionnel, qui décrit ce que la solution doit permettre. Rédigé par la DSI, il garantit que l'outil choisi fonctionnera dans votre système d'information.
Définition
Le cahier des charges technique est la partie du cahier des charges qui fixe le cadre technique dans lequel la solution devra fonctionner. Là où le volet fonctionnel décrit ce que voit l'utilisateur, le volet technique décrit ce que vérifie la DSI : où sont les données, comment on se connecte, avec quels systèmes l'outil échange, quels niveaux de disponibilité et de sécurité il garantit.
Il reste un document d'exigences, pas une conception. Il dit « les utilisateurs se connectent avec leur compte d'entreprise », pas « développez un module d'authentification sur tel serveur ». Imposer une technologie précise n'a de sens que si votre environnement l'exige, et la raison doit alors être écrite.
Ce qu'il contient
| Rubrique | Ce qu'on y précise |
|---|---|
| Environnement existant | Schéma du système d'information, outils en place, annuaire, postes et navigateurs utilisés |
| Hébergement | Mode (SaaS, hébergé, sur site), localisation des données et des sauvegardes, sous-traitants |
| Intégrations | Systèmes à relier, sens et fréquence des échanges, formats, API disponibles |
| Sécurité | Authentification, gestion des droits, chiffrement, journalisation, tests d'intrusion, certifications |
| Performances et disponibilité | Temps de réponse, disponibilité engagée, plages de maintenance, volumes à tenir |
| Exploitation | Sauvegardes et restauration, supervision, montées de version, support technique |
| Normes et réglementation | RGPD, exigences sectorielles, politique de sécurité interne |
| Réversibilité | Export des données, formats, délai, suppression en fin de contrat |
Toutes les rubriques ne pèsent pas autant selon l'achat. Pour un logiciel en ligne, l'hébergement, la sécurité et la réversibilité concentrent l'essentiel ; pour un logiciel installé chez vous, ce sont l'environnement existant et l'exploitation.
Comment rédiger un cahier des charges technique
- Décrire l'existant : un schéma simple du système d'information suffit, avec les outils que la solution devra côtoyer.
- Lister les échanges de données : avec quel système, dans quel sens, à quelle fréquence, sous quel format.
- Reprendre la politique de sécurité de l'entreprise et la traduire en exigences vérifiables.
- Chiffrer les performances et la disponibilité attendues, en distinguant les services critiques des autres.
- Prévoir la sortie : export des données, formats ouverts, délai et coût.
- Attribuer à chaque exigence un identifiant (T-01, T-02…) et une priorité, comme pour les fonctions.
- Demander une preuve pour chaque exigence importante : certificat, rapport d'audit, documentation d'API.
- Faire relire par le responsable de la sécurité et par l'équipe qui exploitera l'outil.
Le piège classique est le copier-coller de la politique de sécurité du groupe, quarante pages que personne ne lira chez le candidat. Mieux vaut quinze exigences précises, chacune avec sa preuve attendue, qu'un document de référence joint en annexe avec la mention « le candidat s'y conforme ». Le candidat cochera « conforme », et vous n'en saurez pas plus.
Exemple pour un logiciel SaaS
Voici un extrait de cahier des charges technique pour un logiciel en ligne, de type outil de notes de frais ou de gestion commerciale. Les valeurs sont des exemples à adapter, pas des recommandations.
| ID | Exigence | Priorité | Preuve attendue |
|---|---|---|---|
| T-01 | Les données et leurs sauvegardes sont hébergées dans l'Union européenne. | Bloquant | Localisation des centres de données, liste des sous-traitants |
| T-02 | Les utilisateurs se connectent avec leur compte d'entreprise (authentification unique, SAML 2.0 ou OpenID Connect). | Bloquant | Documentation, démonstration |
| T-03 | Une double authentification est exigible pour les profils administrateurs. | Important | Démonstration |
| T-04 | La disponibilité mensuelle engagée est d'au moins 99,5 %, hors maintenance annoncée cinq jours ouvrés à l'avance. | Important | Engagement contractuel, historique publié |
| T-05 | Les données sont chiffrées en transit et au repos. | Bloquant | Description des mécanismes |
| T-06 | Une API documentée permet de lire et d'exporter toutes les données. | Important | Documentation de l'API |
| T-07 | Les accès et les actions d'administration sont journalisés et conservés douze mois. | Important | Exemple de journal |
| T-08 | Un test d'intrusion est réalisé chaque année par un tiers. | Important | Synthèse du dernier rapport |
| T-09 | En fin de contrat, toutes les données sont exportées dans un format ouvert (CSV, JSON), puis supprimées. | Bloquant | Procédure de réversibilité, attestation de suppression |
Quelques remarques sur cet extrait. T-02 cite des protocoles, ce qui semble contredire la règle « pas de technologie imposée » ; ce n'est pas le cas, car il s'agit de se brancher sur votre annuaire existant, une contrainte justifiée. T-04 mérite un calcul avant d'être recopié : sur un mois de trente jours, 99,5 % de disponibilité autorisent 3 h 36 d'interruption (720 heures × 0,5 %). Si votre activité ne le supporte pas en pleine journée, demandez plus, et attendez-vous à payer plus. Enfin, la colonne des preuves : un candidat qui doit joindre la synthèse de son dernier test d'intrusion répond avec plus de soin qu'un candidat qui coche une case.
Pour un SaaS, ajoutez à ce tableau l'annexe sur la protection des données que le contrat devra comporter, l'accord de traitement des données (DPA), et les exigences de réversibilité détaillées. Les engagements de disponibilité et de support, eux, se retrouveront dans le SLA.
Cahier des charges fonctionnel et technique
Un cahier des charges fonctionnel et technique réunit les deux volets dans un même document, en deux sections. C'est la bonne formule pour un achat de taille modeste. Pour un projet important, on rédige souvent un cahier des charges fonctionnel et un cahier des charges technique distincts, chacun relu par ses valideurs : le métier pour l'un, la DSI et la sécurité pour l'autre.
Dans les deux cas, chaque exigence n'apparaît qu'une fois. « Les factures validées partent chaque nuit vers la comptabilité » se rédige côté fonctionnel ; le format et le protocole de l'échange, côté technique, avec un renvoi de l'un à l'autre. Nos exemples de cahier des charges (ERP, GED, site web) montrent cette répartition sur des projets concrets.
Publié le 6 octobre 2026