Procédures stockées vs flux de travail visuels : où placer la logique

Ce que cette décision signifie réellement

La logique métier est l'ensemble des règles qui décident ce qui est autorisé, ce qui se passe ensuite et ce que le système doit faire quand de vraies personnes l'utilisent. Ce n'est pas les données elles-mêmes. C'est le comportement : qui peut faire quoi, dans quelles conditions et avec quels effets secondaires.

Ainsi, le débat procédures stockées vs workflows visuels porte en réalité sur l'endroit où ces règles doivent vivre pour rester faciles à changer, difficiles à casser et claires pour les responsables du processus.

La plupart des équipes finissent par avoir trois “maisons” possibles pour la logique :

• Dans la base de données (procédures stockées, triggers, contraintes) : les règles s'exécutent au plus près des données. C'est souvent rapide et cohérent, mais plus difficile à modifier pour des non-spécialistes SQL.
• Dans des workflows visuels (constructeurs processus drag-and-drop) : les règles sont exprimées comme des étapes et des décisions. C'est généralement plus facile à lire, relire et ajuster quand le processus change.
• Dans du code personnalisé (services, applications, scripts) : les règles sont écrites dans un langage de programmation. Cela offre une flexibilité maximale, mais les changements exigent souvent plus de discipline d'ingénierie et de tests.

Le choix influence la vitesse quotidienne et la maintenance à long terme. Mettre la logique au mauvais endroit entraîne des livraisons lentes (chaque changement nécessite la personne qui connaît la base), plus d'erreurs (règles dupliquées) et un débogage pénible (personne ne sait pourquoi un enregistrement a été rejeté).

La plupart des systèmes contiennent plusieurs types de logique métier. Exemples courants : validation (champs requis, plages autorisées), approbations, tarification et remises, notifications et règles d'accès.

Une façon pratique d'y penser : la base de données est excellente pour protéger l'intégrité des données, les workflows visuels permettent d'exprimer les processus métier, et le code personnalisé sert quand la règle est trop unique ou complexe pour être modélisée proprement. Des plateformes comme AppMaster se positionnent au milieu : vous pouvez modéliser les données puis implémenter le processus en logique visuelle lisible sans disperser les règles dans plusieurs applications.

Les critères : ce que vous optimisez

Ce n'est pas une question de goût. Il s'agit de ce que vous cherchez à protéger : les données, les personnes qui changent le système et la vitesse des modifications.

Les résultats qui comptent le plus

Nommez les résultats principaux pour votre projet. La plupart des équipes équilibrent plusieurs de ces points :

• Exactitude : les règles doivent s'exécuter de la même façon à chaque fois, même sous charge.
• Clarté : une personne nouvelle doit comprendre ce qui se passe sans deviner.
• Vitesse : la logique doit s'exécuter rapidement et proche des données quand c'est nécessaire.
• Auditabilité : vous devez prouver qui a changé quoi et quand cela s'est exécuté.
• Taux de changement : vous attendez des exigences qui évoluent chaque semaine, pas chaque année.

Vous maximisez rarement les cinq. Rapprocher la logique de la base peut améliorer l'exactitude et la vitesse, mais réduire la clarté pour ceux qui ne vivent pas en SQL.

Qui changera la logique (et à quelle fréquence)

Soyez honnête sur qui prendra en charge les changements au quotidien. Une règle que l'opération doit ajuster chaque semaine ne devrait pas nécessiter un DBA pour déployer une procédure stockée. À l'inverse, une règle qui affecte de l'argent ne devrait pas être modifiable sans revue.

Pensez en termes de friction au changement. Si les exigences changent souvent, vous voulez un endroit où les mises à jour sont sûres, visibles et rapides à déployer. Les outils de workflow visuel (par exemple le Business Process Editor d'AppMaster) fonctionnent bien quand les responsables métier et les ingénieurs doivent collaborer sur la logique sans éditer du code bas niveau. Si les changements sont rares et la règle critique, une friction plus élevée peut être acceptable.

Une façon rapide de tester la propriété :

• Qui est appelé quand ça casse à 2h du matin ?
• À quelle vitesse devez-vous patcher une règle ?
• Les changements nécessitent-ils des approbations ou une trace papier ?
• Plusieurs applications dépendront-elles de la même règle ?
• La logique est-elle surtout façonnage de données ou décisions métier ?

Notez les contraintes tôt. Certains secteurs exigent un contrôle d'accès strict, une séparation des fonctions ou des logs détaillés. Considérez aussi les limites d'accès aux données : si seuls certains services doivent voir certains champs, cela affecte où la logique peut s'exécuter en toute sécurité.

Quand la logique appartient aux procédures stockées

Les procédures stockées sont des morceaux de logique qui s'exécutent à l'intérieur de la base de données. Dans PostgreSQL, elles sont écrites en SQL (et parfois dans un langage de base comme PL/pgSQL). Plutôt que d'extraire des lignes dans votre appli, boucler et repousser des changements, la base de données fait le travail là où résident les données.

Une bonne règle simple : mettez la logique dans la base quand la tâche principale est de protéger les données et de traiter des volumes, pas de coordonner des personnes ou des systèmes.

Où les procédures stockées excellent

Les procédures stockées conviennent bien aux règles qui doivent toujours être vraies, peu importe l'application ou l'intégration qui touche la base. Pensez aux garde-fous qui empêchent les mauvaises données d'entrer.

Elles excellent aussi pour les mises à jour set-based, où une seule instruction peut mettre à jour des milliers de lignes en toute sécurité et rapidement. Les calculs simples purement liés aux données, comme calculer des totaux ou appliquer une formule de remise fixe, peuvent aussi y vivre si cela réduit les aller-retours et maintient la cohérence des résultats.

Exemple : quand une commande est marquée paid, une procédure peut atomiquement mettre à jour le statut de la commande, décrémenter l'inventaire et écrire une ligne d'audit. Si une étape échoue, l'ensemble est rollbacké.

Quand les procédures stockées deviennent risquées

Les procédures stockées peuvent être plus difficiles à tester et à versionner que le code applicatif, surtout si votre équipe ne considère pas les changements de base comme de vraies releases. La logique peut aussi devenir « cachée » par rapport à l'application, créant un couplage que vous découvrez plus tard.

Le débogage est aussi plus pénible. Les erreurs peuvent apparaître sous forme de messages base de données avec moins de contexte sur l'action de l'utilisateur. Les nouveaux arrivants peuvent être perdus parce que les règles sont réparties entre l'appli et la base, et la logique en base est facile à manquer lors de l'onboarding.

Si vous utilisez un outil visuel pour la plupart de la logique, réservez les procédures stockées au noyau petit et stable qui doit s'exécuter près des données. Gardez le reste là où c'est plus lisible, traçable et modifiable.

Quand la logique va mieux dans les workflows visuels

Les workflows visuels sont des logiques de processus étape par étape que vous pouvez lire comme une checklist : quand quelque chose arrive, exécutez ces actions dans cet ordre, avec des points de décision clairs. Ils sont moins axés sur de lourds calculs et plus sur la manière dont le travail circule entre personnes, systèmes et temps.

Ils brillent quand vous tenez à une compréhension partagée. Si produit, ops, support et ingénierie doivent tous s'accorder sur le fonctionnement d'un processus, un workflow visuel rend les règles visibles. Cette visibilité fait souvent la différence entre « le système est cassé » et « le processus a changé la semaine dernière ».

Les workflows visuels conviennent souvent aux approbations et revues, au routage, aux notifications et rappels, aux étapes temporisées (attendre 2 jours puis escalader), et aux intégrations (appeler Stripe, envoyer un message, mettre à jour un CRM).

Exemple : un client demande un remboursement. Le workflow vérifie l'ancienneté de la commande, oriente vers un manager si elle dépasse un seuil, notifie la finance si approuvé et envoie une mise à jour au client. Chaque étape est facile à pointer et à discuter en langage courant, ce qui aide les parties prenantes à valider et les nouveaux membres à comprendre le « pourquoi ».

Des outils comme le Business Process Editor d'AppMaster sont conçus pour ce type de logique : vous voyez le chemin, les conditions et les effets secondaires (messages, appels API, changements de statut) sans fouiller dans des scripts SQL.

Pour éviter que les workflows deviennent du spaghetti, gardez-les petits et lisibles. Donnez à chaque workflow un seul résultat, utilisez des noms clairs pour les étapes et branches, limitez les décisions profondément imbriquées et loggez les choix clés pour pouvoir répondre plus tard à « pourquoi cela s'est produit ? ».

Quand un workflow commence à faire des calculs complexes ou toucher de nombreuses tables, c'est généralement un signal pour déplacer une partie de la logique ailleurs. Les workflows visuels sont meilleurs en tant que chef d'orchestre, pas en tant qu'orchestre complet.

Quand le code personnalisé est l'outil approprié

Le code personnalisé est la logique que vous écrivez et maintenez comme logiciel : fonctions, services ou petites bibliothèques qui s'exécutent dans votre appli. C'est l'option la plus flexible, et c'est pourquoi elle doit être utilisée intentionnellement, pas par défaut.

Le code mérite sa place quand la logique est difficile à exprimer en toute sécurité dans une procédure de base ou un workflow drag-and-drop. Si vous forcez des outils à rentrer dans un moule inadapté, le code est souvent plus clair et plus facile à maintenir correct.

Signes forts pour choisir le code :

• Le problème est algorithmique (règles de tarification, planification d'itinéraires, scoring, appariement, vérifications antifraude) et comporte beaucoup de cas limites.
• Vous avez besoin d'une intégration inhabituelle (API partenaire avec auth particulière, retries complexes, règles d'idempotence strictes).
• La performance est critique (traitement à haut volume, calculs lourds, cache précis) et vous avez besoin d'un contrôle fin.
• Vous devez partager la même logique à plusieurs endroits (web, mobile, jobs batch) sans la copier.
• Vous avez besoin de tests automatisés solides autour de la logique parce que les erreurs coûtent cher.

Le code clarifie aussi la propriété : une équipe peut être responsable des revues, de maintenir les tests au vert et de documenter le comportement. C'est mieux que « ça vit dans trois workflows et personne n'est sûr lequel s'exécute en premier ».

Exemple : un moteur de décision de remboursement qui prend en compte l'historique des commandes, signaux antifraude, statut d'expédition et fenêtres temporelles. Vous pouvez garder les étapes d'approbation dans un workflow visuel, mais la décision elle-même est souvent mieux en code avec des tests unitaires et du contrôle de version.

Le coût est réel. Le code personnalisé demande du temps d'ingénierie, des revues et une maintenance continue. Les changements peuvent prendre plus de temps que d'éditer un workflow, et vous avez besoin d'un processus de release. AppMaster peut réduire la quantité de code nécessaire en couvrant les parties communes avec de la logique visuelle et des modules, tout en permettant aux équipes d'exporter le code source et d'étendre là où c'est vraiment nécessaire.

Un cadre étape par étape réutilisable

Les équipes sautent souvent la partie la plus utile : écrire clairement la règle, puis choisir une “maison” qui correspond au comportement de la règle.

Utilisez ce cadre à chaque fois qu'une nouvelle logique apparaît :

• Écrivez la règle en une phrase, puis étiquetez-la. Si elle concerne des données valides (contraintes, unicité, totaux qui doivent correspondre), c'est une règle de données. Si elle concerne des étapes et des transferts (approbations, attentes, notifications), c'est une règle de processus. Si c'est des calculs lourds ou des transformations complexes, c'est une règle de computation.
• Demandez qui la modifie et à quelle fréquence. Si des non-techniciens doivent la changer chaque semaine, ne l'enterrez pas en SQL ou dans un release de code. Si elle change rarement et doit être appliquée à chaque fois, la base est un meilleur candidat.
• Vérifiez l'impact d'une erreur et la traçabilité nécessaire. Si une erreur peut entraîner une perte d'argent, des problèmes de conformité ou des données difficiles à réparer, préférez un endroit avec un logging clair et un contrôle strict.
• Choisissez l'emplacement et définissez la frontière. Soyez explicite sur les entrées, sorties et erreurs. Exemple : « Given an order_id, return allowed_refund_amount or a clear reason code. » Cette frontière empêche la logique de se répandre partout.
• Choisissez une couche à garder mince. Décidez ce qui doit rester essentiellement « stupide » pour ne pas dupliquer les règles. Choix courants : base de données mince (intégrité des données), workflows minces (orchestration) ou code mince (glue).

Règle pratique : rapprochez les règles de données des données, placez les règles de processus dans un outil de workflow et mettez les règles de computation là où elles sont les plus faciles à tester et versionner.

Si vous utilisez une plateforme comme AppMaster, vous pouvez considérer la base comme des garde-fous (tables, relations, contraintes basiques) et utiliser le Business Process Editor pour la partie « qui fait quoi ensuite », en réservant le code personnalisé aux rares cas qui en ont vraiment besoin.

Erreurs courantes qui rendent les systèmes confus

Les systèmes confus ne viennent rarement d'un seul mauvais choix. Ils surviennent quand la logique est dispersée, cachée ou copiée jusqu'à ce que personne ne sache vraiment ce que fait le système.

La duplication est le problème classique : la même règle existe à deux endroits mais dérive avec le temps. Exemple : la base rejette les remboursements supérieurs à 500$ sauf s'il y a un enregistrement d'approbation, mais un workflow envoie quand même la demande de remboursement au paiement parce qu'il vérifie une limite différente. Les deux « fonctionnent » jusqu'au premier vrai cas limite, puis le support obtient un bug mystérieux.

Les règles cachées suivent. Triggers, procédures stockées et correctifs rapides en base peuvent être invisibles pour ceux qui construisent l'UI ou les workflows. Si la règle n'est pas documentée près du workflow ou de l'API qui en dépend, les changements deviennent du tâtonnement et les tests tournent au essai/erreur.

Les workflows surchargés créent un autre type de désordre. Une longue chaîne drag-and-drop avec des dizaines de branches devient un artefact fragile que personne n'ose toucher. Dans des outils comme AppMaster, il est facile d'ajouter des blocs parce que c'est rapide, mais la vitesse d'aujourd'hui peut se transformer en confusion si le workflow n'a pas de frontières claires.

Deux erreurs opposées « trop » causent de la douleur à long terme :

• Trop dans la base : chaque changement de politique devient un projet de migration et les petites modifications produit attendent des releases base.
• Trop dans le code appli : les règles de base (champs requis, statuts autorisés, contraintes d'unicité) sont oubliées et les mauvaises données passent via des imports, outils admin ou futures intégrations.

Une habitude simple prévient la plupart de ces problèmes : gardez chaque règle dans une maison primaire, et notez où elle vit et pourquoi. Si vous ne pouvez pas répondre « où est-ce appliqué ? » en 10 secondes, vous payez déjà la taxe du désordre.

Vérifications rapides : décider en 2 minutes

Vous choisissez l'endroit où une règle est la plus facile à garder correcte, visible et changeable.

Commencez par une question : cette règle concerne-t-elle la correction des données, c'est-à-dire doit-elle ne jamais pouvoir être contournée ? Si oui, poussez-la vers la base. Si elle concerne des étapes, approbations ou notifications, gardez-la plutôt dans la couche workflow.

Une checklist rapide :

• Est-ce que ça fait respecter la correction des données (empêcher un inventaire négatif, bloquer des enregistrements « actifs » dupliqués) ? Penchez base.
• Touche-t-elle de nombreuses tables et nécessite-t-elle des mises à jour set-based ? Penchez base.
• Avez-vous besoin d'une trace lisible par un humain de qui a approuvé quoi et quand ? Penchez workflow.
• Des non-ingénieurs devront-ils la changer chaque semaine ou mois ? Penchez workflow.
• Appelle-t-elle des services externes (paiements, messagerie, AI) ? Penchez application ou workflow, pas la base.

Pensez maintenant à l'échec. Une règle qui peut échouer doit le faire de façon récupérable par des humains.

Si vous avez besoin de retries sûrs et de messages d'erreur clairs, préférez une couche d'orchestration où vous pouvez tracer l'état et gérer les exceptions étape par étape. Les outils de workflow visuel facilitent souvent cela parce que chaque étape est explicite et peut être journalisée.

Un critère de départ pratique :

• Si le système doit rester correct même quand quelqu'un écrit une nouvelle application plus tard, faites-valoir la règle dans la base.
• Si le processus doit être lu et validé par les équipes ops, gardez-le dans un workflow visuel.
• Si cela implique des intégrations complexes, des calculs lourds ou des bibliothèques spéciales, utilisez du code personnalisé.

Exemple : « Le montant du remboursement ne peut pas dépasser le paiement initial » est une contrainte de correction, donc appliquez-la près des données. « Les remboursements supérieurs à 500$ nécessitent une approbation manager puis envoient un message Telegram » est un workflow. Dans AppMaster, cette chaîne d'approbation trouve naturellement sa place dans le Business Process Editor, tandis que les contraintes strictes restent dans le modèle de données.

Scénario exemple : remboursements avec approbations

Un cas courant est un remboursement nécessitant une approbation manager au-delà d'un certain montant, plus des notifications et une traçabilité propre.

Commencez par définir une source de vérité : un seul enregistrement Refund avec montants et un champ statut clair (par exemple : requested, needs_approval, approved, rejected, processing, paid, failed). Toutes les parties du système doivent lire et écrire ces mêmes champs, au lieu de garder des états parallèles.

Ce qui appartient à la base de données

Mettez les règles qui protègent l'argent et la cohérence des données le plus près possible des données.

Utilisez des contraintes (et parfois une procédure stockée) pour s'assurer que vous ne pouvez pas rembourser plus que le montant capturé, rembourser une commande déjà entièrement remboursée, créer deux demandes actives pour la même commande ou modifier des montants clés après approbation du remboursement.

Conservez aussi la mise à jour atomique ici : quand une demande de remboursement est créée, écrivez la ligne Refund et mettez à jour les totaux de la Commande dans une seule transaction. Si l'un des deux écrit échoue, rien ne doit être partiellement mis à jour.

Ce qui va mieux dans un workflow visuel

Les étapes d'approbation sont du processus, pas de la protection des données. Un workflow visuel est un bon lieu pour orienter la demande vers le bon manager, attendre une décision, mettre à jour le statut, envoyer des rappels et notifier le demandeur.

Un flux simple pourrait être : créer la demande -> si le montant dépasse la limite, mettre le statut à needs_approval -> notifier le manager -> si approuvé, mettre approved -> notifier le demandeur -> si pas de réponse en 24h, envoyer un rappel.

Dans un outil comme AppMaster, cela se mappe clairement à un Business Process qui réagit aux changements de statut et déclenche email, SMS ou messages Telegram.

Ce qui doit être du code personnalisé

Les fournisseurs de paiement ont des cas limites qui ne rentrent pas toujours proprement dans des règles ou des étapes drag-and-drop. Gardez la logique spécifique aux fournisseurs dans du code personnalisé : remboursements partiels avec frais ou paiements multi-capture, réconciliation de webhooks (le fournisseur dit « paid » mais votre appli dit « processing »), et gestion d'idempotence et de retries quand le fournisseur timeoute.

L'essentiel est que le code personnalisé ne devrait pas inventer ses propres statuts. Il lit l'enregistrement Refund, effectue l'action auprès du provider, puis écrit le statut suivant et les montants confirmés afin que la base reste le grand livre de référence.

Étapes suivantes : pérenniser le choix

Une bonne décision n'aide que si elle tient six mois plus tard. L'objectif est de rendre votre choix « où habite cette logique ? » facile à voir, simple à tester et difficile à contourner accidentellement.

Créez une carte de logique simple : une courte liste de vos règles clés et le domicile choisi pour chacune. Gardez-la brève et mettez-la à jour quand une règle change. Incluez le nom de la règle, où elle vit (base, workflow, code personnalisé), pourquoi (une phrase), ce qu'elle lit et écrit, et qui approuve les changements.

Écrivez des frontières comme non négociables qui protègent votre système quand on ajoute des fonctionnalités plus tard. Un format utile est : « La base garantit X » et « Les workflows font respecter Y. » Par exemple, la base garantit qu'un enregistrement Refund ne peut pas exister sans une commande, tandis que le workflow impose que les remboursements supérieurs à 500$ nécessitent une approbation manager.

Planifiez les tests avant de changer quoi que ce soit. Pas besoin d'un grand plan de test, juste quelques cas que vous rejouerez à chaque modification de règle :

• Happy path (entrée attendue, résultat attendu)
• Chemin d'échec (données manquantes, statut invalide, double demande)
• Concurrence (deux personnes déclenchant la même action en même temps)
• Sécurité (un utilisateur essayant de sauter des étapes ou d'appeler un endpoint directement)

Définissez aussi la propriété et les règles de revue. Décidez qui peut modifier les procédures stockées, qui peut éditer les workflows et ce qui nécessite une revue par les pairs. C'est souvent là que les systèmes restent sains ou dérivent vers « personne ne sait pourquoi cela marche ».

Si vous voulez des workflows drag-and-drop sans sacrifier une vraie structure backend, une plateforme comme AppMaster (appmaster.io) peut être un compromis pratique : modélisez vos données, exprimez le processus dans le Business Process Editor et régénérez et déployez quand les exigences changent.

Choisissez une règle à fort impact, cartographiez-la, ajoutez les frontières et écrivez trois cas de test. Cette seule habitude prévient la plupart de la dispersion de la logique.