Un cahier des charges d'automatisation doit permettre à une autre personne de comprendre le processus, chiffrer le même périmètre et vérifier la livraison. Décrivez le résultat attendu, les données, les règles, les exceptions, les accès et la reprise en cas d'échec. Reliez chaque exigence importante à un exemple et à une preuve observable.
À quoi sert un cahier des charges d'automatisation ?
Le cahier des charges transforme une idée générale en résultat métier testable. Il permet à l'équipe et au prestataire de parler du même processus, de comparer les propositions sur un périmètre commun et de décider si la livraison répond au besoin.
Le document n'a pas besoin de choisir Make, n8n, une API ou un modèle d'IA. Il doit d'abord répondre à des questions fonctionnelles : quel événement lance le travail, quelles informations entrent, quelles décisions changent la suite, quel résultat doit apparaître, qui traite les exceptions et comment prouver que l'action a réussi ?
Cette précision sert à trois moments distincts :
- Avant le devis, pour éviter que deux prestataires chiffrent des périmètres différents sous le même intitulé.
- Pendant la réalisation, pour arbitrer sans réinventer le besoin à chaque échange.
- À la réception, pour tester des scénarios convenus plutôt que juger une démonstration idéale.
Commencez par un processus limité. L'article Comment cartographier un processus avant de l'automatiser ? explique comment suivre une tâche réelle de son déclencheur à son résultat. Le cahier des charges reprend cette carte et ajoute la cible, les preuves, les responsabilités et les conditions d'exploitation.
Que doit contenir le cahier des charges ?
Un document utile couvre le besoin, le fonctionnement réel, le résultat cible et les conditions de réception. Chaque rubrique doit aider à prendre une décision ou à vérifier un résultat ; retirez les pages de contexte qui ne changent ni le périmètre ni la solution.
| Rubrique | Question à résoudre | Preuve ou livrable attendu |
|---|---|---|
| Problème et objectif | Quel résultat métier veut-on améliorer ? | Situation de départ et résultat observable |
| Périmètre | Où le flux commence-t-il et se termine-t-il ? | Éléments inclus, exclus et reportés |
| Processus actuel | Qui fait quoi, dans quel outil et dans quel ordre ? | Carte relue à partir de cas récents |
| Données | Quelles informations sont nécessaires et d'où viennent-elles ? | Liste des champs, sources et données obligatoires |
| Règles et exceptions | Qu'est-ce qui change la suite ou bloque le traitement ? | Cas nominal, variantes et responsable de chaque reprise |
| Actions et accès | Que peut lire, créer, modifier, envoyer ou supprimer le système ? | Comptes, habilitations et limites par outil |
| Acceptation | Comment décider que chaque scénario fonctionne ? | Jeux d'essai, résultats attendus et traces |
| Livraison | Que reçoit l'entreprise à la fin ? | Configuration ou code, documentation, formation et accès |
| Exploitation | Qui surveille, corrige et fait évoluer le flux ? | Alertes, support, maintenance et procédure de sortie |
Ajoutez une priorité à chaque exigence : indispensable pour le premier périmètre, souhaitable ensuite ou hors périmètre. Cette distinction évite de transformer toutes les idées en conditions de lancement.
Le guide France Num sur le cahier des charges, publié en mars 2026 pour les projets de site, recommande notamment de prioriser, nommer les responsables, définir des critères de validation et prévoir les coûts récurrents ainsi que la maintenance. Ces principes de pilotage restent utiles pour une automatisation, même si ses spécifications diffèrent de celles d'un site.
Comment décrire le besoin sans commencer par l'outil ?
Décrivez d'abord des cas réels et le résultat attendu. Un nom de logiciel peut être une contrainte si l'entreprise l'utilise déjà, mais il ne remplace pas la règle métier ni la manière de vérifier le travail.
Prenez un dossier récent qui a suivi le chemin habituel, puis un dossier qui a demandé une reprise. Pour chacun, relevez :
- l'événement de départ et les informations disponibles ;
- les contrôles effectués par la personne ;
- la règle qui autorise ou refuse la suite ;
- l'action réalisée dans chaque outil ;
- le résultat visible et les traces conservées ;
- l'exception rencontrée, la décision humaine et la reprise.
Écrivez ensuite le flux cible en langage métier. Par exemple : « lorsqu'un formulaire complet arrive, créer une seule fiche dans le CRM, conserver la source, attribuer le bon responsable et renvoyer l'identifiant de la fiche ». Cette exigence laisse ouverte la solution technique, mais elle fixe déjà les contrôles essentiels.
Séparez enfin les contraintes des préférences. Une contrainte peut être l'hébergement imposé, l'absence d'API, la conservation d'une validation humaine ou un logiciel qui ne peut pas être remplacé. Une préférence est un outil envisagé, une interface souhaitée ou une technologie familière. Le prestataire peut challenger une préférence ; il doit respecter ou expliciter une contrainte.
Comment rendre les règles et les exceptions testables ?
Transformez chaque scénario important en cinq éléments : entrée, règle, action, preuve et reprise. Cette structure évite les formulations comme « synchroniser correctement les données », qui ne disent ni ce qui est correct ni comment le vérifier.
- Entrée : exemple précis reçu par le système, avec les champs présents ou manquants.
- Règle : condition qui décide de la suite, avec sa source métier.
- Action : lecture, création, modification, notification ou préparation autorisée.
- Preuve : identifiant, statut, journal ou comparaison permettant de contrôler le résultat.
- Reprise : personne alertée, informations visibles et action possible si le traitement s'arrête.
De l'exemple métier au test
- EntréeUn cas réel et ses données
- RègleLa condition qui décide
- ActionCe que le système peut faire
- PreuveLa trace qui confirme le résultat
- RepriseLa personne et l'action en cas d'arrêt
Pour une demande de devis, le cas nominal peut exiger une fiche unique avec les champs obligatoires et un responsable attribué. Une adresse déjà connue devient un cas de doublon : le système ne crée pas de seconde fiche, signale la correspondance et laisse une personne choisir entre mise à jour et abandon.
Le critère d'acceptation décrit le résultat observable, pas la manière de programmer. Associez-lui un exemple d'entrée et le résultat attendu. Pour une IA, ajoutez aussi les réponses interdites, les cas d'incertitude et l'action qui reste soumise à validation humaine. L'article Comment tester un agent IA avant sa mise en production ? détaille la constitution de ces scénarios.
Comment cadrer les accès, les données et la sécurité ?
Le cahier des charges doit préciser les accès nécessaires et les limiter au périmètre réel. Un flux qui lit des demandes et prépare un brouillon n'a pas besoin, par défaut, du droit de supprimer des clients ou d'envoyer un message définitif.
Pour chaque logiciel, indiquez :
- le compte qui portera l'intégration et son propriétaire ;
- les opérations autorisées en lecture et en écriture ;
- les données utilisées, leur source et leur destination ;
- les personnes habilitées à consulter les traces ou à relancer un dossier ;
- l'environnement et les données employés pour les tests ;
- la procédure de retrait des accès à la fin de la mission.
Lorsque des données personnelles sont traitées, l'analyse dépend du contexte et ne se résume pas à une case « RGPD ». La CNIL recommande d'intégrer les profils d'accès et la protection des données dès la conception. Le responsable du traitement doit déterminer les obligations applicables au projet et documenter les choix adaptés.
Prévoyez aussi les secrets techniques. Les mots de passe et clés d'API ne doivent pas circuler dans le cahier des charges. Le document indique qui fournit les accès, où ils sont conservés, comment ils sont renouvelés et qui peut les révoquer.
Quels livrables et responsabilités faut-il prévoir ?
La livraison comprend le système, les moyens de le contrôler et la capacité de le reprendre. Une automatisation qui fonctionne aujourd'hui mais dont personne ne possède les comptes, la documentation ou les alertes crée une dépendance difficile à évaluer.
Précisez au minimum :
- ce qui est livré, par exemple configuration, code, connecteurs, modèles ou tableaux de suivi ;
- l'endroit où ces éléments sont hébergés et à qui appartiennent les comptes ;
- la documentation du flux, des règles, des accès et des actions manuelles ;
- les journaux et alertes accessibles à l'équipe ;
- la formation ou la passation prévue ;
- la période de correction après réception et ce qu'elle couvre ;
- la maintenance récurrente, son déclenchement et son prix ;
- la procédure d'export, de désactivation ou de transfert à un autre intervenant.
Le dossier France Num sur l'automatisation, mis à jour en juillet 2026, recommande de tester le scénario complet, surveiller les échecs, documenter les règles et prévoir la maintenance. Un changement de formulaire, de champ CRM, de règle métier ou d'API peut suffire à modifier un flux qui fonctionnait au lancement.
Définissez enfin qui décide. Une personne côté entreprise valide les règles et les cas de test. Le prestataire explique les conséquences techniques et signale les limites. Les utilisateurs qui exécutent le processus vérifient les exemples ; ils ne portent pas seuls la décision budgétaire ou le risque accepté.
Comment comparer deux devis d'automatisation ?
Comparez les devis sur les scénarios, les responsabilités et l'exploitation, pas seulement sur le nombre d'étapes ou le nom des outils. Deux propositions peuvent afficher « formulaire vers CRM » tout en couvrant des réalités différentes.
Vérifiez ces points sur une même ligne de comparaison :
| Point à comparer | Question concrète |
|---|---|
| Périmètre | Les mêmes sources, destinations et variantes sont-elles incluses ? |
| Données | Le nettoyage, les doublons et les champs manquants sont-ils traités ? |
| Actions | Les limites de lecture, d'écriture, d'envoi et de suppression sont-elles explicites ? |
| Tests | Les cas nominaux, exceptions et preuves attendues sont-ils compris ? |
| Livraison | Les comptes, la documentation et les accès appartiennent-ils à l'entreprise ? |
| Exploitation | Les alertes, corrections, évolutions et coûts récurrents sont-ils indiqués ? |
| Sortie | Peut-on désactiver, exporter ou transférer le système sans perdre les données ? |
Un montant plus bas peut correspondre à un périmètre plus étroit, ce qui n'est pas un défaut si la limite est claire. L'article Combien coûte une automatisation pour une PME ? explique comment les intégrations, les exceptions, les contrôles et le temps interne influencent le coût total.
Demandez à chaque intervenant de reformuler le flux et de montrer comment il réceptionnera un cas incomplet ou un échec. Cette réponse révèle mieux la compréhension du besoin qu'une longue liste de technologies.
Que montre le cas d'un agent de recherche commerciale ?
Le cas d'un négociant en vins montre comment un besoin devient spécifiable. Le client recherchait manuellement des cavistes et des grossistes, appliquait ses critères, puis enregistrait les résultats dans son CRM.
Nous avons d'abord explicité les sources consultées, les critères d'exclusion et les informations à conserver. J'en ai fait un agent qui exécute ces étapes et enregistre une liste qualifiée. Plusieurs passes ont été nécessaires pour ajuster la qualification à la méthode du client. Le choix des entreprises à contacter reste humain.
Un cahier des charges pour ce flux devrait distinguer la recherche, la qualification, l'écriture dans le CRM et la décision de contact. Il devrait aussi conserver la source qui permet de contrôler chaque résultat. Le cas ne fournit ni gain mesuré ni protocole complet publiable ; il montre pourquoi les critères métier et la limite de l'action doivent être écrits avant la réalisation.
Le cas Brest Bretagne Handball illustre un autre besoin : relier des outils pour automatiser des transferts back-office auparavant manuels. Pour une mission comparable, le cahier des charges préciserait les informations transférées, la destination, la preuve de réception et la personne alertée si le transfert échoue. Les réalisations présentent ces interventions au niveau de détail publiable.
Quand un brief léger suffit
Un document court peut suffire pour un flux limité, réversible, fondé sur des règles stables et connecté à peu d'outils. Il doit tout de même fixer le déclencheur, le résultat, les exclusions, deux ou trois exemples, les droits d'accès, les critères d'acceptation et la personne qui reprend les erreurs. La précision compte davantage que le nombre de pages.
Ce qu'il faut retenir
- Décrivez un résultat métier limité avant de choisir la technologie.
- Reliez chaque scénario à une entrée, une règle, une action, une preuve et une reprise.
- Écrivez les limites d'accès, les responsabilités, les livrables et la maintenance.
- Comparez les devis sur le même périmètre et les mêmes critères de réception.
- Adaptez la longueur du document au risque et à la complexité, sans retirer les éléments nécessaires au test.
Pour cadrer un premier projet, apportez un processus récent, les logiciels concernés et une exception réellement rencontrée. Nous pouvons transformer ces éléments en premier périmètre pendant un échange gratuit de 30 minutes.
Questions fréquentes
Un brief peut résumer le problème, l'objectif et le contexte pour lancer les échanges. Le cahier des charges va plus loin : il fixe le périmètre, les règles, les contraintes, les critères de réception et les responsabilités. Pour un petit flux, les deux peuvent tenir dans un même document court.
Seulement si l'outil constitue une contrainte réelle, par exemple parce qu'il est déjà utilisé ou ne peut pas être remplacé. Sinon, décrivez le besoin, les données, les accès et le résultat attendu ; la solution technique pourra être comparée séparément.
La personne qui connaît le processus apporte les cas réels et valide les règles. Le responsable du projet fixe les priorités et accepte les risques. Un prestataire peut structurer le document et signaler les implications techniques, mais l'entreprise reste responsable du besoin métier qu'elle valide.
Il n'existe pas de longueur universelle. Un premier flux simple peut tenir en quelques pages avec des exemples et des critères précis ; plusieurs systèmes, des données sensibles ou de nombreuses exceptions demandent plus de détail. Le test utile consiste à vérifier si une autre personne peut chiffrer et réceptionner le même périmètre.
Écrit par Antoine mazu. Antoine aide les petites entreprises de services à comprendre et améliorer leurs processus grâce à des solutions adaptées, avec ou sans IA. Basé à Bayonne, il associe réflexion produit et réalisation technique.
Sources : France Num, dossier sur l'automatisation des TPE-PME, publié le 14 novembre 2025 et mis à jour le 9 juillet 2026 ; France Num, bâtir un cahier des charges, publié le 20 mars 2026 et mis à jour le 23 mars 2026 ; CNIL, encadrer les développements informatiques, publiée le 14 mars 2024 ; approche d'Antoine mazu ; réalisations d'Antoine mazu. Pages relues le 21 septembre 2026.
