Vos processus méritent un logiciel adapté.

Règles métier, transactions et modifications concurrentes

Une application doit aussi fonctionner correctement lorsque plusieurs personnes modifient simultanément le même stock. Deux réservations ne doivent pas attribuer le même dernier article sans que personne ne s'en aperçoive. Nous déterminons donc quelles modifications doivent réussir ensemble et quels conflits nécessitent un retour métier. Les contraintes de base de données, les transactions et les contrôles de version peuvent résoudre différentes parties de cette tâche ; l'interface seule ne peut pas garantir ces règles.

En revanche, les processus métier plus longs ne tiennent souvent pas dans une seule transaction. Une commande, un service de paiement externe et une validation d'expédition ont chacun leurs propres états d'erreur. Nous modélisons le déroulement avec des états traçables et des transitions autorisées. Les requêtes répétées reçoivent un identifiant de dossier approprié, afin qu'une interruption de connexion ne déclenche pas automatiquement une double action. En cas d'erreur partielle, une correction définie sur le plan métier est nécessaire, par exemple l'annulation d'une validation, plutôt qu'un redémarrage technique global.

Locataires, rôles et traçabilité des accès aux données

Pour les produits SaaS et les plateformes internes, nous distinguons l'identité d'un utilisateur de ses droits sur un enregistrement de données concret. Un collaborateur connecté ne doit pas pouvoir lire automatiquement chaque facture ou chaque commande. Nous vérifions les accès côté back-end au niveau de l'organisation, du rôle et du dossier. Les exports, les index de recherche, les tâches en arrière-plan et les résultats mis en cache doivent eux aussi respecter ces limites.

Des tables communes avec un indicateur de locataire, des schémas de base de données séparés ou des bases de données propres impliquent des exigences différentes en matière d'isolation, de migration et de restauration. Nous choisissons le modèle en fonction de la séparation nécessaire et de votre organisation d'exploitation. Des tests avec plusieurs locataires vérifient en particulier les accès non autorisés. Un journal d'audit documente les modifications pertinentes sur le plan métier avec un contexte approprié ; les données qu'il contient et leur durée de disponibilité sont définies de manière explicite.

Stockage des données, performance et extensibilité à long terme

La structure des données suit les requêtes et les règles métier. Nous examinons les filtres, tris, analyses et opérations d'écriture typiques avant d'introduire des technologies de stockage supplémentaires. Des listes de résultats illimitées, des requêtes individuelles répétées et de gros transferts de données peuvent ralentir une application, même si le serveur semble à peine sollicité. Des mesures avec des volumes de données réalistes montrent si des index, des modifications de requêtes, la pagination ou une autre répartition des tâches peuvent aider.

La mise en cache est une décision délibérée sur la fraîcheur des données : il doit être établi quand un résultat stocké devient invalide et quels utilisateurs peuvent le voir. Les calculs volumineux peuvent s'exécuter comme des tâches en arrière-plan, mais nécessitent alors un indicateur d'avancement, une reprise et des états d'erreur. Pour les extensions, nous séparons les règles métier des adaptateurs techniques. Des tests automatisés et des modifications versionnées de la base de données protègent ces limites, afin qu'un nouveau canal ou un autre fournisseur n'oblige pas à modifier chaque module.