No-code : quand un process RH critique lâche

L’essentiel : Chez Aquiris, filiale belge du groupe Veolia, l’onboarding et les départs de collaborateurs reposaient sur un montage no-code bricolé, Pipefy pour le workflow, Zoho Sign pour la signature, relié à la main. J’ai reconstruit ce process en vraie application, FastAPI et HTMX, déployée sur leur propre serveur. En production interne depuis le 4 juin 2026.

Un process RH qui tenait sur deux SaaS reliés à la main

Aquiris est client Digitis depuis 2022 pour la téléphonie, une centaine de postes. C’est leur responsable technique, qui travaille avec Digitis sur plusieurs sujets depuis des années, qui m’a parlé du sujet. Il savait ce que je faisais de mon côté avec le développement assisté par IA, et il connaissait un problème qui traînait chez eux depuis un moment.

Leur process d’onboarding et de départ de collaborateurs tournait sur un montage no-code depuis environ un an. Pipefy gérait le workflow, les étapes, les tâches à cocher. Zoho Sign gérait la signature des documents. Les deux outils faisaient leur travail correctement pris isolément. Le problème se logeait entre les deux : rien ne les reliait vraiment, sinon des habitudes et des copier-coller de statut d’un outil à l’autre.

Ce genre de montage fonctionne tant que le volume reste faible et que la même personne s’en occupe à chaque fois. Il produit du flou dès que la question se pose autrement : où en est ce dossier précis, a-t-on bien envoyé le rappel de signature, qui doit signer en premier. Des questions simples, auxquelles personne ne pouvait répondre avec certitude sans rouvrir les deux outils et recouper à la main. C’est ce type de situation que je traite avec le développement d’application sur mesure : remplacer l’assemblage de SaaS par une application qui porte elle-même la logique du process.

Quand faut-il quitter le no-code pour une vraie application ?

Trois signaux disent qu’un montage no-code a dépassé son rôle d’outil et qu’il est devenu une dépendance non documentée. Plusieurs SaaS enchaînés à la main pour accomplir un seul travail, sans API ni synchronisation réelle entre eux. Personne qui puisse dire avec certitude où en est un dossier à un instant donné, sans rouvrir plusieurs interfaces et recouper. Et une seule personne qui connaît les réglages qui font tourner l’ensemble, dont l’absence bloque tout.

Pris isolément, aucun de ces signes n’est grave. Réunis, ils veulent dire que le no-code ne fait plus gagner de temps, il en coûte, de façon diffuse et difficile à chiffrer. C’est le moment de basculer vers une application qui porte elle-même la logique du process, au lieu de la reconstituer à chaque incident.

Ce qui coinçait concrètement chez Aquiris

L’utilisatrice principale de l’outil était la responsable RH, non technique, qui n’avait ni le temps ni la vocation de devenir experte Pipefy. Deux problèmes revenaient régulièrement.

Le premier, c’est l’absence de suivi daté fiable. Impossible de dire avec certitude quand une demande de signature était partie, ni quand un rappel avait été envoyé. L’information existait quelque part, éclatée entre deux interfaces, mais elle n’était pas centralisée ni consultable d’un coup d’œil.

Le second, c’est l’enchaînement des signatures. Un dossier d’arrivée ou de départ suppose souvent une signature interne d’abord, puis une signature côté candidat ou collaborateur. Dans le montage d’origine, cet enchaînement séquentiel ne se déclenchait pas tout seul, il fallait le relancer manuellement à chaque étape.

Il y avait aussi la dépendance à des SaaS facturés à l’usage, sans que personne chez Aquiris n’ait vraiment la main sur la logique du workflow lui-même. Le jour où on veut changer une étape, on ne modifie pas son propre outil, on négocie avec les limites de configuration d’un tiers.

Pourquoi une vraie application, et pas un autre outil no-code

J’ai construit l’application en Python, avec FastAPI côté serveur, des pages rendues en Jinja2 et HTMX pour l’interactivité. Pas un framework JavaScript lourd type React ou Next.js. Ce n’est pas de la nostalgie, c’est un choix fait pour ce client-là.

L’outil sert une petite équipe RH, pas un million d’utilisateurs. Le serveur sur lequel il tourne, chez le client, dispose de deux vCPU et 3,3 Go de RAM. Une chaîne de build front moderne, avec ses dépendances qui évoluent tous les six mois, n’a aucune raison d’exister pour un usage pareil : c’est une source de pannes futures que personne chez Aquiris n’a la vocation de maintenir dans deux ans. Moins de pièces mobiles, c’est moins de choses qui cassent, et surtout une seule personne, chez eux ou en repreneur externe, doit pouvoir rouvrir le code et comprendre ce qui se passe.

La base de données suit la même logique : SQLite plutôt que PostgreSQL. Un fichier, un usage mono-serveur, un nombre de fiches qui reste modeste. Une sauvegarde consiste à copier ce fichier. Aucune administration de serveur de base de données à part, aucun cluster à surveiller pour un volume qui ne le justifie pas.

Le vrai luxe, dans ce genre de projet, ce n’est pas d’utiliser la technologie la plus récente. C’est de livrer une technologie que le client pourra encore faire tourner sans moi, dans cinq ans, avec l’équipe qu’il a sous la main à ce moment-là.

Reconstruire proprement, sans budget d’agence

Le développement a été assisté par IA, avec des itérations courtes en boucle directe avec la responsable RH. Elle testait en signant réellement des documents pendant qu’on avançait, pas sur une maquette figée présentée en fin de projet.

Deux galères, parce qu’un récit de chantier sans galère est un récit truqué. La première : l’intégration à l’API Zoho Sign recréait un client OAuth à chaque appel. Résultat, un rate-limit, un “too many requests” en pleine phase de test avec la cliente. Le correctif tient en une ligne, mettre le jeton d’authentification en cache au lieu d’en redemander un à chaque requête. Simple une fois identifié, invisible avant de tomber dedans.

La seconde concerne le mode automatique, censé enchaîner les étapes sans intervention. Il ne se déclenchait jamais. J’ai tenté deux correctifs le même jour, tous les deux à côté de la plaque, avant de trouver la vraie cause en fin de journée. Ça fait partie du travail.

Avant la remise, deux passes de contrôle qualité ont été menées. Un audit sécurité a été effectué, avec zéro faille critique restante à la fin du processus. Une revue de code a sorti trois bugs réels, dont un particulièrement instructif : le statut des signataires était rapproché par adresse e-mail, ce qui faisait que deux signataires partageant la même adresse s’écrasaient mutuellement dans le suivi. Corrigé en passant par un identifiant d’action propre à chaque étape plutôt que par l’adresse mail. Le tout accompagné de 48 tests automatisés qui couvrent les parcours principaux.

Le résultat

L’application est passée en production interne le 4 juin 2026. Un parcours complet d’arrivée en CDI a été validé de bout en bout ce jour-là, en réel, avec un vrai dossier.

Elle tourne sur le serveur d’Aquiris, hors de mon infrastructure, dans la même logique que notre cloud européen : les données restent chez celui à qui elles appartiennent. J’ai remis une documentation de maintenance à leur équipe informatique, et cette maintenance reste volontairement hors contrat. Ils ne dépendent pas de moi pour que ça continue de tourner.

C’est le même choix de stack que celui qui fait tourner ma propre facturation opérateur automatisée. Je ne livre pas à un client une architecture que je ne voudrais pas maintenir moi-même.

Pour qui ça vaut le coup (et pour qui non)

Si votre process tourne sur du no-code et qu’il reste secondaire, stable, avec un volume qui ne bouge pas, il n’y a aucune raison d’en partir. Le no-code existe précisément pour ces cas-là, et il fait le travail sans qu’on ait besoin d’y toucher.

Ce qu’il faut surveiller, c’est l’écart entre la criticité du process et la solidité de son architecture. Un process RH qui gère des arrivées et des départs, avec des documents à signer et une obligation de traçabilité, grimpe en criticité plus vite qu’on ne l’anticipe. Le montage, lui, ne bouge pas. C’est là que ça finit par casser, et rarement à un moment qui vous arrange.