Développement & mise en œuvre

De la spécification à l'intégration : OTOKO® développe des applications et les relie à vos systèmes et processus existants.

Qu'il s'agisse d'une application métier, d'un produit numérique ou d'un outil interne : nous développons des logiciels pour les processus qui ne peuvent pas être représentés de manière pertinente avec les systèmes existants.

Analyse des exigences avec le service métier, modèle de menaces et architecture cible selon le modèle C4 Modèle de domaine, modèle de données et contrats d'interface avant la première ligne de code Développement en itérations courtes avec revues de code et recettes par le service métier Développement sécurisé selon OWASP ASVS, dépendances vérifiées et builds signés Transfert avec code source, documentation d'architecture et manuel d'exploitation

Application opérationnelle avec code source et pipeline de build Documentation d'architecture avec modèle de menaces Manuel d'exploitation avec runbooks et plan de secours

Exemples des processus de travail actuels et de leurs exceptions Responsables des décisions métier Systèmes existants, sources de données et exigences d'exploitation

La planification de la maintenance est jusqu'ici gérée dans des tableurs. Une application métier regroupe les installations, les échéances, les responsabilités et les validations. La première étape couvre un site ; les autres sites ne sont ajoutés qu'après une vérification métier du processus.

.NET C# Go Rust TypeScript PostgreSQL

Le point de départ est le processus de travail qui doit justifier l'investissement. Nous modélisons les notions, les états et les règles métier avec les personnes qui utiliseront ensuite l'application. Une validation, par exemple, ne se résume pas à un bouton : la suppléance, les autorisations, les délais et l'annulation d'une décision doivent s'articuler. Ces règles font partie du modèle de données et des tests. La première version se concentre sur un processus complet et utilisable. Nous ajoutons d'autres fonctions en fonction des retours du terrain. Il en résulte un produit dont l'utilité est vérifiable, et non une vaste collection d'écrans inachevés.

Pour le back-end, l'interface utilisateur et le stockage des données, nous choisissons les technologies en fonction de votre paysage applicatif existant et de son évolution attendue. Les compétences existantes, les interfaces et les exigences d'exploitation pèsent alors plus lourd qu'une tendance technologique passagère. L'offre actuelle comprend notamment .NET, Go et TypeScript ; les composants proches du système sont évalués séparément. Nous définissons les limites entre modules et les responsabilités de sorte que les modifications restent traçables. Les identifiants d'accès n'ont pas leur place dans le code source, et les règles métier ne doivent pas résider uniquement dans l'interface. Les revues, les contrôles automatisés et les modifications versionnées de la base de données accompagnent la mise en œuvre dès le début.

Chaque itération présente des fonctions utilisables avec leurs limites connues. La recette métier et la validation technique sont considérées séparément : une commande correctement calculée peut être juste sur le plan métier, alors que le comportement en charge ou la gestion des erreurs ne sont pas encore prêts pour la production. Nous définissons ensemble les preuves nécessaires pour chaque étape d'extension. Le périmètre de livraison convenu comprend le code source, des builds reproductibles et la documentation. Pour le démarrage en production, nous clarifions la reprise des données, la formation, les responsabilités et la gestion des incidents. Les droits d'utilisation, les composants tiers et la maintenance ultérieure sont réglés avant le transfert.

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.

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.

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.

Parc applicatif, exigences, risques Métiers, DSI, sécurité de l'information, architecte logiciel d'OTOKO® Projets évalués, état des lieux, exigences de sécurité et d'exploitation

Architecture, technologie, modèle d'exploitation Métiers, architecture, protection des données, sécurité de l'information Architecture cible, modèle de menaces, stratégie de test, modèle d'exploitation, jalons