Rédiger un cahier des charges pour un projet d'automatisation

Un cahier des charges d'automatisation n'est pas un cahier des charges de machine

Si vous avez déjà rédigé un cahier des charges pour l'achat d'une ligne de production ou d'une machine spéciale, oubliez le réflexe. Ce n'est pas le même exercice.

Pour une machine, vous spécifiez une cadence, des tolérances, une conformité mécanique, un test d'acceptation en atelier. Le livrable est physique, il se voit, il se mesure au pied à coulisse. Pour une automatisation logicielle, surtout quand elle mêle des flux et de l'IA, le livrable est un comportement. Il faut décrire non pas une pièce, mais une suite de décisions : quand l'outil agit seul, quand il demande, quand il s'arrête et prévient un humain.

C'est cette différence qui piège tout le monde. Un cahier des charges d'automatisation mal écrit ressemble à une liste de vœux : « l'outil doit gérer les commandes, traiter les mails, mettre à jour l'ERP ». Chacune de ces phrases cache trois semaines de développement et dix cas particuliers non dits. Le prestataire chiffre au doigt mouillé, gonfle pour se couvrir, et vous voilà avec un devis à cinq chiffres pour un besoin qui en valait la moitié.

Le bon cahier des charges fait l'inverse. Il réduit l'incertitude. Il dit précisément ce que l'outil doit faire, sur quel volume, avec quelles données en entrée, quel résultat en sortie, et où s'arrête son autonomie. Plus c'est précis, moins c'est cher, et plus le résultat vous ressemble.

Le processus visé et son volume, avant tout le reste

La première erreur, c'est de commencer par la solution. « On veut une IA qui lit les mails. » D'accord, mais pour quoi faire, à partir de quel volume, et pour résoudre quel problème concret ?

Un cahier des charges honnête commence par décrire le processus réel, celui qui tourne aujourd'hui, avec ses défauts. Pas le processus idéal du manuel qualité. Le vrai. Qui reçoit quoi, qui recopie où, qui relance qui, où ça bloque, combien de fois par jour. Si vous ne savez pas cartographier ce flux, c'est le premier signal qu'il faut le faire avant d'automatiser quoi que ce soit. On en parle en détail dans notre méthode pour auditer un processus avant de l'automatiser.

Ensuite, le volume. C'est le chiffre qu'on oublie le plus souvent, et c'est celui qui change tout.

Automatiser le traitement de dix commandes par jour et de mille commandes par jour, ce n'est pas le même projet, ni le même budget, ni la même architecture. À faible volume, une automatisation simple suffit et se rentabilise vite sur le temps gagné. À fort volume, il faut penser fiabilité, reprise sur erreur, montée en charge, et ça change la conception dès le premier jour. Un cahier des charges qui ne dit pas « on traite environ 300 factures fournisseurs par mois, avec un pic à 500 en fin de trimestre » force le prestataire à deviner. Et un prestataire qui devine, il devine cher.

Notez aussi la saisonnalité. Une clôture comptable qui concentre 80 % du travail sur trois jours pose des contraintes qu'un flux lissé ignore. Écrivez-le.

Les entrées et les sorties, décrites au format près

Une automatisation, au fond, c'est une fonction. Quelque chose entre, quelque chose sort. Le cahier des charges doit décrire les deux bouts avec une précision presque bête.

Côté entrées, listez tout ce qui déclenche ou nourrit le traitement. Un mail avec une pièce jointe PDF. Un fichier déposé dans un dossier partagé. Une ligne créée dans l'ERP. Un formulaire rempli sur l'intranet. Une photo prise à l'atelier. Pour chaque entrée, précisez le format réel, pas le format théorique. Un « PDF de facture » peut être un beau PDF texte propre, ou un scan de travers d'un fax reçu par un fournisseur qui vit encore en 2005. Ces deux-là ne se traitent pas pareil, et l'écart de difficulté est énorme.

Le diable se cache dans la variété. Vos fournisseurs vous envoient-ils tous le même modèle de facture ? Non, évidemment. Combien de formats différents ? Cinq ? Cinquante ? Un cahier des charges sérieux donne une idée de cette dispersion, parce qu'une IA de lecture de documents gère très bien la variété, mais encore faut-il l'avoir dit pour la tester sur de vrais échantillons.

Côté sorties, même rigueur. Où va le résultat ? Une ligne écrite dans Sage ou Divalto. Un mail de réponse rédigé et mis en brouillon. Un tableau de bord mis à jour. Un ticket créé dans un outil de suivi. Précisez le format attendu, le niveau de finition, et surtout qui reçoit la sortie et qu'en fait-il ensuite. Une sortie que personne ne lit, c'est du travail automatisé pour rien.

Et donnez de vrais exemples. Trois factures d'entrée avec les trois lignes qu'elles doivent produire en sortie valent mieux que deux pages abstraites. Le prestataire comprend en trente secondes ce qu'il n'aurait pas saisi en une réunion d'une heure.

Les cas particuliers, là où naissent les usines à gaz

Voici la partie que presque tout le monde bâcle. Et c'est celle qui décide si votre projet reste raisonnable ou part en vrille.

Un processus, sur le papier, a l'air simple. Une commande arrive, on la saisit, on la confirme. En vrai, il y a la commande sans référence claire, celle qui dépasse l'encours client autorisé, celle du client qui a changé d'adresse sans prévenir, celle en devise étrangère, celle qui mélange trois produits dont un en rupture. Ce sont les exceptions. Elles représentent peut-être 15 % des cas. Elles coûtent souvent 60 % de l'effort d'automatisation.

Le piège classique : vouloir tout automatiser, exceptions comprises, dès la première version. C'est exactement comme ça qu'on construit une usine à gaz. On empile des règles pour couvrir des cas rares, le système devient illisible, personne ne le maintient, et le moindre nouveau cas non prévu le casse.

La bonne approche est plus modeste et plus efficace. Le cahier des charges liste les cas particuliers connus, honnêtement, sans les cacher. Puis il décide, pour chacun : est-ce qu'on l'automatise, ou est-ce qu'on le laisse remonter à un humain ? Traiter proprement les cas standards et router les cas tordus vers une personne, c'est souvent 90 % du gain pour 40 % du coût. Vous automatiserez le reste plus tard, si le volume le mérite.

Écrivez donc noir sur blanc ce que l'outil ne fait pas. C'est aussi utile que la liste de ce qu'il fait. Une automatisation qui sait dire « ce dossier sort de mon périmètre, je le passe à Sophie » est mille fois plus fiable qu'une automatisation qui tente de tout gérer et se trompe une fois sur cinq sur les cas limites.

Les outils à connecter, le périmètre technique réel

Une automatisation ne vit pas seule. Elle se branche sur votre existant. Le cahier des charges doit nommer précisément ce qu'il faut connecter, parce que la connexion est souvent la partie la plus délicate et la plus coûteuse.

Listez vos logiciels avec leur nom et leur version. Pas « notre ERP », mais « Sage 100 version X » ou « Divalto Infinity ». Pas « notre messagerie », mais Microsoft 365 ou Google Workspace. La question qui suit chaque nom : cet outil expose-t-il une API, un connecteur, une base accessible ? Certains logiciels s'ouvrent facilement, d'autres sont des forteresses. Un ERP maison développé il y a quinze ans peut n'avoir aucune porte d'entrée propre, et il faudra alors passer par des contournements moins élégants. Mieux vaut le savoir avant de signer. Notre article sur connecter une IA à votre ERP détaille les cas de figure.

Précisez aussi la brique d'orchestration. Beaucoup d'automatisations reposent sur un outil de flux comme n8n ou Make, qui relie les briques entre elles, déclenche les traitements et gère les erreurs. Le choix entre ces outils n'est pas neutre pour le coût et la maintenance ; on compare les principaux dans n8n, Make et Zapier. Quant à la partie intelligence, celle qui lit un document, comprend un mail ou classe un dossier, elle passe chez nous par Claude, le modèle d'IA d'Anthropic. On y envoie le minimum de données nécessaire au traitement, ces données ne servent pas à entraîner le modèle, et on choisit le modèle selon l'enjeu.

Un mot sur la confidentialité, puisque la question tombe toujours. Le cahier des charges doit dire quelles données sont sensibles. Un numéro de facture n'a pas le même poids qu'un dossier client sous litige. Pour le sensible, on limite ce qui sort vers les services d'IA et on le garde sous validation humaine. Vos données restent maîtrisées quand ces règles sont écrites au départ, pas rajoutées en catastrophe après.

Le niveau de validation humaine, la clause qui vous protège

C'est la clause qu'on oublie et qui rattrape tout le monde. Jusqu'où l'automatisation agit-elle seule, et à partir de quand un humain valide ?

Le réflexe naïf serait de tout automatiser à fond pour maximiser le gain. Mauvaise idée. Une automatisation qui envoie un mail au mauvais client, valide un paiement en trop ou classe une non-conformité grave en mineure, ça coûte plus cher que le temps qu'elle fait gagner. Le curseur de l'autonomie se règle selon le risque de chaque action, pas selon l'envie d'aller vite.

Dans le cahier des charges, décrivez trois niveaux pour chaque type de tâche. Ce que l'outil fait seul et sans demander, parce que l'erreur y est bénigne et rare. Ce qu'il prépare mais qu'un humain valide avant exécution, parce que ça engage l'argent ou la relation client. Ce qu'il ne touche pas du tout et se contente de signaler, parce que la décision demande un jugement qu'aucun modèle ne remplace. Ce principe de garder l'humain sur les décisions qui comptent, on l'applique partout ; il est développé dans notre article sur les règles à poser entre RPA et IA.

Un exemple parle mieux qu'une théorie. Sur une relance d'impayés, l'outil peut détecter les factures échues et préparer les mails de relance sans problème : c'est mécanique. Envoyer le premier rappel poli, courant, peut se faire seul. Mais la relance ferme au client historique qui pèse 20 % de votre chiffre, celle-là, un humain la relit avant qu'elle parte. Le cahier des charges pose cette frontière noir sur blanc, et l'outil s'y tient.

Des critères de succès mesurables, pas des intentions

Comment saurez-vous que le projet a réussi ? Si vous ne pouvez pas répondre par des chiffres, le cahier des charges n'est pas fini.

« Gagner du temps » n'est pas un critère. C'est un souhait. Un critère, c'est : le traitement d'une facture fournisseur passe de 6 minutes à moins d'une minute de temps humain. Le taux de commandes traitées sans intervention atteint 80 %. Le délai moyen de réponse à un appel d'offres passe de trois jours à un jour. Le taux d'erreur de saisie reste sous 1 %.

Chaque critère a besoin de deux valeurs : le point de départ, mesuré aujourd'hui, et la cible visée. Sans le point de départ, vous ne pourrez jamais prouver le gain. C'est pour ça qu'on mesure avant de développer : le chiffre d'avant est aussi la preuve du chiffre d'après.

Fixez aussi ce qui compte au-delà du temps. La qualité, avec un taux d'erreur toléré. La traçabilité, si vous êtes sur du contrôlé par une norme ISO ou un référentiel IFS où chaque étape doit laisser une trace. La reprise en cas de panne, parce qu'une automatisation qui tombe un vendredi soir sans que personne le sache, c'est un lundi matin catastrophe. Ces critères-là ne se voient pas dans une démo. Ils s'écrivent en amont, sinon on les découvre au pire moment.

Reliez enfin chaque critère à une méthode de vérification : comment on mesure, sur quelle période. Sinon le jour de la recette, chacun défend son interprétation, et le projet se termine sur un désaccord au lieu d'un chiffre.

La maintenance et la réversibilité, pour ne pas se retrouver prisonnier

Un projet d'automatisation ne s'arrête pas à la livraison. Il vit. Vos fournisseurs changent de format, votre ERP se met à jour, un modèle d'IA évolue, un cas nouveau apparaît. Le cahier des charges doit anticiper cette vie-là.

Posez la question de la maintenance dès le départ. Qui corrige quand ça casse ? En combien de temps ? À quel coût ? Une automatisation livrée sans contrat de maintenance clair, c'est une bombe à retardement. Le jour où elle plante et que personne ne répond, vous revenez au traitement manuel en catastrophe, avec en prime un arriéré à rattraper.

Exigez aussi la documentation et l'accès. Vous devez pouvoir comprendre comment l'outil est bâti, où sont les clés, comment on le débranche proprement. Une automatisation dont vous ne maîtrisez ni le code, ni les accès, ni la logique, c'est une laisse. Le jour où vous voulez changer de prestataire, vous ne pouvez pas. C'est un critère de choix qu'on développe dans notre guide pour choisir un prestataire d'automatisation : la réversibilité se négocie avant de signer, jamais après.

Un modèle de structure à réutiliser

Voici le squelette qu'on utilise pour cadrer un projet. Adaptez-le à votre cas, mais gardez les rubriques. Chacune répond à une question qui, si elle reste sans réponse, finit par coûter cher.

• Contexte et objectif : quel problème concret on résout, et pourquoi maintenant. Deux paragraphes, pas plus.
• Processus visé, tel qu'il tourne vraiment : le flux actuel avec ses étapes, ses acteurs, ses points de blocage. Le vrai, pas l'idéal.
• Volume et fréquence : combien de dossiers par jour ou par mois, avec les pics et la saisonnalité.
• Entrées : chaque source qui déclenche ou nourrit le traitement, son format réel, sa variété, avec des exemples authentiques.
• Sorties : le résultat attendu, sa destination, son format, et qui l'utilise ensuite.
• Cas particuliers : la liste honnête des exceptions, et pour chacune la décision automatiser ou router vers un humain.
• Outils à connecter : logiciels nommés et versionnés, disponibilité d'une API ou d'un connecteur, brique d'orchestration, modèle d'IA.
• Données sensibles : ce qui est confidentiel, ce qui peut sortir vers un service d'IA, ce qui passe par validation humaine.
• Niveau de validation humaine : pour chaque action, ce que l'outil fait seul, ce qu'il prépare pour validation, ce qu'il se contente de signaler.
• Critères de succès : chaque objectif chiffré, avec sa valeur de départ mesurée, sa cible, et la façon de le vérifier.
• Maintenance et réversibilité : qui corrige et sous quel délai, la documentation fournie, les accès rendus, la possibilité de reprendre la main.
• Périmètre exclu : ce que le projet ne couvre pas, écrit noir sur blanc pour éviter les malentendus.

Ce document tient souvent en cinq à huit pages pour un premier processus. S'il en fait trente, c'est qu'on cherche à tout couvrir d'un coup, et c'est le moment de découper.

L'erreur à éviter par-dessus tout

Vouloir la perfection avant de commencer.

On voit des entreprises repousser un projet pendant des mois parce que le cahier des charges n'est « pas encore complet ». Pendant ce temps, l'équipe recopie toujours ses factures à la main. Un cahier des charges n'a pas besoin d'être parfait. Il a besoin d'être honnête et précis sur un périmètre raisonnable. On l'affine au fil de l'audit, sur de vrais échantillons, avec les gens qui font le travail. C'est d'ailleurs le cœur de notre méthode : mesurer, cadrer un premier périmètre net, livrer vite, puis élargir.

Le meilleur cahier des charges n'est pas le plus long. C'est celui qui permet à un prestataire de vous chiffrer juste, et à vous de vérifier après coup que vous en avez eu pour votre argent. Tout le reste est du remplissage.