Méthodologie d'automatisation des process : Étude de cas Paie

C'est un petit chantier, qui sera surtout l'occasion de parler méthodologie.

L'expression du besoin

Cette étape consiste à repérer le pain point. Chez nous, c'est facile : mon super-pouvoir, c'est d'avoir la flemme. Tout ce qui ne m'intéresse pas doit disparaître, d'une manière où d'une autre.

Dans la langue des consultants, on appelle ça la méthode "lean" : ça vient de chez Toyota, et ça a ensuite été formalisé au Massachussets Institute of Technology. Le principe, c'est de dire qu'avec une bonne organisation du travail, on peut réduire au minimum le temps qui n'a pas de valeur ajoutée, sans nuire à la qualité du produit final.

Dans notre étude de cas, c'est vite compris : je veux continuer de payer mes salariés, mais y passer moins de temps.

Modélisation du process

Ensuite, on doit écrire le process en détails, en étudiant bien les entrées et sorties de chaque étape. Pour le moment, on ne réfléchit pas : on constate.

On utilise les services de notre cabinet comptable, qui gère aussi le social.
Chaque mois, notre gestionnaire de paie, Martine, m'envoie un email avec un seul PDF, qui contient toutes les fiches de paie.

J'ai un petit utilitaire en ligne de commande (pdftk) qui me permet de les découper (une fiche par personne), puis direction Qonto pour faire les virements, où, pour chaque fiche :

je saisis manuellement le montant : je ne me rappelle jamais s'il faut mettre une virgule ou un point, j'ai toujours peur de me tromper. Chaque saisie manuelle, c'est le premier "flag" qu'on peut peut-être faire quelque chose.
je sélectionne le destinataire, parmi tous les fournisseurs de l'Agence (ou je tape son nom pour le chercher - on passe 10 fois de la souris au clavier),
je valide sur mon téléphone pour chaque virement.
j'envoie la fiche de paie au salarié

Points d'attention critique, qui serviront aussi de premiers critères d'acceptation :

les virements DOIVENT partir à date,
les montants DOIVENT être corrects,
les données NE PEUVENT PAS partir dans la nature,
un virement NE DOIT PAS pouvoir être envoyé deux fois.

Dans le monde de l'informatique, pour éviter toute ambiguïté dans une documentation ou une spécification technique, on utilise des mots précis définis par l'IETF (Internet Engineering Task Force), publiés dans la RFC 2119 (qui date de 1997). Les contraintes critiques sont énoncées en majuscules. Ça évite les termes vagues.

Les critères d'acceptation, c'est la liste de ce qu'on doit trouver impérativement dans le résultat. C'est une preflight checklist : si on ne peut pas tout cocher, l'avion ne décolle pas. Ce n'est pas négociable.

Est-ce qu'on doit automatiser ?

À ce stade, la question doit être posée : doit-on vraiment automatiser ça ? D'un côté, ça ne me prend "que" 20 minutes une fois par mois. Mais d'un autre...

On se moque souvent gentiment du développeur, cette bête étrange qui passe deux jours à automatiser un truc qui lui prend deux heures, mais si c'est le dev qui passe deux jours, et vous qui gagnez deux heures, je ne vois pas où est le problème. D'autant plus que ce genre de tâches doivent être faites, mais ce n'est certainement pas ce qui me donne envie de me lever le matin.

Argument supplémentaire : on réduit le risque d'erreur, puisqu'on ne copiera plus de montants à la main.

Dans notre cas, on va le faire. Mais dans une boîte qui n'est pas encore "lean", on aura sûrement plein d'autres leviers à aller chercher avant d'en arriver là.

Pour nos histoire de fiches de paie, je ne sais pas encore si je vais simplement fluidifier le process (et le documenter au passage, ça sera une bonne chose de faite), coder un petit script, trouver un produit sur étagère qui règle mon problème, ou déployer une flotte d'agents IA sur un serveur GPU (dans l'ordre de mes préférences).

Négocier les contraintes

Pour choisir notre angle d'attaque, maintenant qu'on a modélisé le process, on essaie de négocier avec les contraintes. L'idée, c'est de chercher des pistes pour faciliter la tâche, sans chercher à l'effacer.

Je pourrais éviter de passer par un email, si le logiciel de paie proposait une API ou un webhook. Une API, c'est une norme de programmation, qui pourrait être suivie par l'éditeur du logiciel de Martine, qui me permet de "piloter" un système à distance et d'aller chercher mes infos de paie (pull). Un webhook, c'est un dispositif de mon côté, qui réagit quand on lui envoie des infos, pour que le logiciel me prévienne quand il y a de nouvelles fiches (push). Rien de tout ça n'est disponible : on doit garder l'email.
Je pourrais faire sauter l'étape de découpage, si Martine m'envoyait directement un fichier par personne. Je lui ai posé la question, et ce n'est pas possible, son logiciel ne le gère pas. Logique : dans la plupart des boîtes classiques, on imprime toutes les fiches de paie d'un coup, et on les distribue sur papier, remise en main propre, directement dans l'open space. On n'aura que le fichier global.
Je pourrais m'éviter de tout retaper côté banque. Qonto (notre banque adorée) dispose d'une API solide (dont la documentation qui m'intéresse aujourd'hui est ici), qui permet notamment d'initier des paiements sortants en masse (on appelle ça "en bulk"). Enfin une bonne nouvelle.
Je pourrais envoyer la fiche de paie automatiquement. Quand on a des gens de l'équipe qui vivent à l'étranger, c'est obligatoire. Je ne peux décemment pas imprimer une page et l'envoyer par la Poste à l'autre bout du monde chaque mois. Mais il y a des contraintes. L'envoi dématérialisé est permis depuis la Loi Travail de 2016, et je sais que mes salariés ne s'y opposeront pas. Chez un client, c'est un point qu'il faut vérifier (et préparer un "fallback" pour le jour où quelqu'un fera valoir son droit d'opposition). L'envoi par email est toléré pour les petites structures mais idéalement, il faut un coffre-fort électronique, et ça tombe bien, puisqu'on est déjà équipés de ce côté-là (pas de détails, pour des raisons évidentes de confidentialité et de sécurité). Ok, pas besoin d'imprimer (ouf).

Réflexion technique

À ce stade, j'ai une meilleure compréhension des différentes options qui se présentent à moi.

Voilà mon process technique :

Quand arrive un email de Martine avec une pièce jointe en PDF, appelée "machin-202602.pdf", on découpe la pièce jointe : lire la date, le nom du salarié et le net à payer. Si le virement a déjà été envoyé (donc on historise), on ne fait rien. Ensuite, on passe par l'API de Qonto pour envoyer les virements.

Le fait de ne pas envoyer en double, ça s'appelle de l'idempotence, et c'est hyper important. Si mon script tourne deux fois, on n'envoie pas deux fois les salaires (désolé). S'il plante au milieu, il doit pouvoir reprendre où il s'est arrêté. Généralement, on passe par un identifiant unique, par exemple "paie_[nom][annee][mois]", soit "paie_carole_2026_02" : si cette clé est trouvée, c'est que le virement est déjà parti. Triple-avantage : ça marche à chaque fois, c'est aussi lisible pour un humain (ça peut aider au débug), et ça nous évite de stocker les montants et compagnie.

Ok.

Aucune trace d'IA là-dedans. L'utilisation des LLMs se justifie quand on a du flou, ce qui n'est pas le cas ici.

La partie la plus fragile, ça sera le "data mining" du PDF, mais ça tiendra tant que le format du fichier restera le même. On ne parle pas de son contenu (nouvelles cotisations) mais bien de sa structure. On devrait être tranquilles un moment.

Ébauche technique : choisir ses combats

Lire un email, stocker trois clés d'idempotence et taper dans une API, n'importe quel langage fait ça. J'aurais pu sortir du Python, ou m'amuser sur un outil No-code type Make ou N8N.

Mais on a déjà un intranet en PHP qui tourne très bien. On va juste lui rajouter une feature.

Pourquoi ? Pour éviter ce que j'appelle la prolifération de surface : c'est le piège classique où on rajoute de la technique partout sans stratégie et où on finit avec une brique de script à droite, un outil d'automatisation à gauche, et un agent IA au milieu. Au final, on n'a pas supprimé une tâche, on a déplacé le problème vers la maintenance d'une usine à gaz. Et maintenir des outils éparpillés, c'est l'inverse du Lean.

Pour un client, la logique est la même, mais l'échelle change. Quand on arrive sur un chantier avec 200 pain points, on ne va pas coder 200 scripts isolés. On bâtit un "réceptacle" (une application ou une plateforme centrale) qui servira de hub pour toutes les automatisations futures (CRM, stocks, RH). Et on ne règlera pas forcément les 200, même si c'est la situation idéale : chaque minute travaillée a une vraie valeur ajoutée pour l'entreprise. À la place, on va formaliser un process de priorisation, et traiter les choses les plus importantes en premier. Reste à définir ensemble ce qu'on estime être important (ça peut être une discussion philosophie de deux heures - et j'adore ça).

L'idée reste la même : centraliser pour ne plus y penser.

Pourquoi on s'inflige ça ?

On pourrait croire que c'est juste un délire de dev qui veut s'amuser avec une API. En réalité, c'est le cœur de notre métier chez LVLUP.

Si on ne sait pas descendre dans les rouages (comprendre comment un PDF est foutu, ce qu'est une clé d'idempotence, ou comment une API dialogue avec une banque) on fait du conseil de salon. On finit par pondre des recommandations que personne ne pourra appliquer, parce que dans le vrai monde, "le logiciel de Martine ne le permet pas".

À l'inverse, coder pour coder sans prendre de la hauteur sur le besoin, c'est le meilleur moyen de construire un truc complexe qui ne règle pas le bon problème.

C'est cette double casquette qu'on porte :

D'un côté, on fait le ménage : on challenge vos process, on négocie avec vos contraintes et on vire ce qui n'a pas de valeur.
De l'autre, on met les mains dans le cambouis : on construit les ponts techniques qui manquent pour que ça tourne tout seul.

Si vous avez un process qui vous donne envie de démissionner tous les 30 du mois, ou une "Martine" (on les adore, mais pas leurs outils) qui bloque votre croissance : venez nous voir. On regardera ensemble si on peut simplifier le bazar, et si besoin, on sortira les lignes de code pour que vous n'ayez plus jamais à cliquer dix fois sur le même bouton.