Aller au contenu principal
FromNine
Menu

Ingénierie

Développement de logiciels métier sur mesure et de produits SaaS, conçus pour durer

Nous développons des produits SaaS, des portails pour les citoyens et les collaborateurs et des applications métier critiques, accessibles, sécurisés par défaut et maintenables par vos propres équipes bien après leur lancement.

Pour les éditeurs, grands comptes et organismes publics qui veulent un logiciel métier qu’ils pourront maintenir, faire évoluer et auditer pendant des années.

Échanger sur votre projetDécouvrir notre approche
Logiciels métier et SaaS : les couches de la solutionQuatre couches superposées en profondeur. De haut en bas : l’interface accessible utilisée par les personnes, les modules métier qui portent les règles, les services de plateforme pour la gestion multi-locataire et l’identité, et la chaîne de livraison sécurisée en dessous.01Interfaces accessibles02Modules et règles métier03Multi-locataire, identité, données04Chaîne de livraison sécurisée
  1. 01Une conception pilotée par le domaine (DDD) pour les activités riches en règles, comme l’instruction de dossiers
  2. 02Une accessibilité conforme à la norme EN 301 549 et aux WCAG 2.2 AA dès le premier sprint
  3. 03Une documentation et des dossiers de décision que vos équipes peuvent reprendre

01 Enjeux

Ce que nous entendons avant une refonte

  1. 01

    Chaque évolution prend un trimestre

    L’application fonctionne, mais personne n’ose toucher au cœur. La moindre modification exige de lourds tests de non-régression et une fenêtre de mise en production.

  2. 02

    Le portail ne sert pas les personnes auxquelles il est destiné

    Il ne fonctionne ni avec un lecteur d’écran, ni dans toutes les langues de ses usagers, ni sur mobile. Les plaintes arrivent avant l’audit d’accessibilité.

  3. 03

    L’évolution d’un client casse celle d’un autre

    Le produit SaaS a grandi à coups de spécifiques par client. Chaque version est désormais une négociation, et certains locataires restent bloqués sur d’anciennes versions.

  4. 04

    Le savoir est parti avec le prestataire

    Les décisions n’ont jamais été consignées. L’équipe qui a construit l’application est passée à autre chose, et le code est la seule documentation.

  5. 05

    Les questions de sécurité arrivent des clients et des régulateurs

    Les acheteurs demandent un SBOM, un processus de gestion des vulnérabilités et des éléments de preuve au titre du règlement européen sur la cyberrésilience (Cyber Resilience Act). Personne ne les a sous la main.

02 Prestations

Ce que nous livrons

  1. 01 Ingénierie de produits SaaS

    Des produits conçus pour servir de nombreux clients à partir d’une seule base de code : le bon modèle multi-locataire, du paramétrage plutôt que du spécifique, et des versions qui atteignent chaque locataire.

    Ce que nous faisons

    • Choix du modèle multi-locataire : partagé, mutualisé ou isolé par locataire
    • Stratégie de paramétrage et de feature flags
    • Intégration du comptage d’usage et de la facturation
    • Trains de livraison avec déploiement progressif par locataire

    Ce que vous recevez

    • Conception du modèle multi-locataire et de l’isolation
    • Modèle de paramétrage avec garde-fous
    • Processus de livraison avec retour arrière par locataire

  2. 02 Conception métier pour des règles complexes

    Une conception pilotée par le domaine lorsque les règles sont le produit : instruction de dossiers, conditions d’éligibilité, calculs encadrés par la réglementation. Nous arbitrons honnêtement entre monolithe modulaire et microservices, et commençons le plus souvent par le premier.

    Ce que nous faisons

    • Event storming avec les experts métier
    • Contextes délimités et frontières de modules
    • Règles rendues explicites et testables
    • Dossiers de décision d’architecture (ADR) pour les choix structurants

    Ce que vous recevez

    • Modèle du domaine et carte des contextes
    • Base de code modulaire aux frontières contrôlées
    • Spécifications exécutables pour les règles clés

  3. 03 Portails citoyens et collaborateurs

    Des interfaces bâties sur un design system, accessibles par défaut et multilingues dès la première version. En Belgique, cela signifie trois langues officielles ; ailleurs, les langues que parlent réellement vos utilisateurs.

    Ce que nous faisons

    • Design system aux composants accessibles
    • Rédaction des contenus en langage clair
    • Tests avec des utilisateurs réels de technologies d’assistance
    • Processus de localisation pour chaque langue

    Ce que vous recevez

    • Portail sur un design system réutilisable
    • Rapport de conformité en accessibilité
    • Processus de gestion des contenus et des traductions

  4. 04 Ingénierie de la qualité et développement sécurisé

    Une automatisation des tests aux bons niveaux, des tests de contrat entre services, des tests de performance avant le lancement, et un cycle de développement sécurisé fondé sur l’OWASP ASVS, les SBOM et la maîtrise de la chaîne d’approvisionnement logicielle.

    Ce que nous faisons

    • Stratégie et automatisation des tests
    • Tests de contrat et de performance
    • Modélisation des menaces et vérification ASVS
    • Génération de SBOM et politique de dépendances

    Ce que vous recevez

    • Suites de tests automatisés dans la chaîne CI/CD
    • Rapport de vérification de sécurité
    • Processus de gestion des vulnérabilités prêt pour le Cyber Resilience Act

  5. 05 Modernisation progressive

    Remplacer une application existante fonctionnalité par fonctionnalité, derrière une façade de routage, sans interrompre l’activité. Voir aussi la modernisation des systèmes hérités.

    Ce que nous faisons

    • Cartographie des fonctionnalités de l’application existante
    • Routage selon le modèle strangler fig et encapsulation par API
    • Migration des données avec rapports de rapprochement
    • Exécutions en parallèle pour les calculs critiques

    Ce que vous recevez

    • Séquence de modernisation avec jalons métier
    • Façade et nouveaux modules en production
    • Données rapprochées à chaque bascule

  6. 06 Maintenabilité et passation

    Un logiciel que vos équipes peuvent s’approprier : un code lisible, des dossiers de décision, des procédures d’exploitation et un plan de passation convenu au départ, pas découvert à la fin.

    Ce que nous faisons

    • Binômage avec vos développeurs pendant la réalisation
    • Dossiers de décision d’architecture tenus à jour avec le code
    • Procédures d’exploitation et guides d’astreinte
    • Jalons de transfert de connaissances

    Ce que vous recevez

    • Plan de passation avec critères de recette
    • Documentation dans vos dépôts
    • Équipe interne formée

03 Architecture

Une architecture de référence illustrative

Une forme typique pour une application métier qui en remplace une plus ancienne : une interface accessible, une façade de routage qui oriente chaque fonctionnalité vers l’ancien ou le nouveau système, une couche d’API aux contrats clairs, et un cœur modulaire organisé autour du domaine métier.

La gestion multi-locataire et le paramétrage sont des services de plateforme explicites, pas des conditions dispersées dans le code. En dessous, chaque build exécute les tests et les contrôles de sécurité et produit un SBOM.

Couches du schéma

Utilisateurs
Citoyens, clients et collaborateurs, sur tout terminal et avec les technologies d’assistance.
Modernisation
La façade de routage, l’application existante et la migration des données avec rapprochement.
Plateforme
Couche d’API, identité, cœur modulaire, multi-locataire et paramétrage, données opérationnelles.
Livraison sécurisée
Tests de contrat et de performance, contrôles ASVS et SBOM à chaque build.
Exemple illustratif

  1. Utilisateurs

    • Citoyens, clients, collaborateurs
    • Interface accessible

  2. Modernisation progressive

    • Façade de routage
    • Application existante
    • Migration avec rapprochement

  3. Plateforme

    • Couche d’API et contrats
    • Identité et rôles
    • Cœur modulaire : réception, dossiers, facturation
    • Multi-locataire, paramétrage, feature flags
    • Bases de données opérationnelles

  4. Livraison sécurisée

    • Tests de contrat et de performance, contrôles ASVS, SBOM à chaque build
Un cœur modulaire derrière une façade de routage

Architecture illustrative, pas un système client.

Lire le schéma sous forme de texte

Le parcours principal va des utilisateurs à une interface accessible, puis traverse une façade de routage et une couche d’API jusqu’à un cœur modulaire organisé en contextes délimités.

La façade oriente aussi certaines fonctionnalités vers l’application existante, retirée étape par étape. Ses données rejoignent les bases opérationnelles au moyen d’une migration avec rapprochement.

L’identité sert la couche d’API. Les services multi-locataire et de paramétrage se situent sous le cœur. Une bande de livraison sécurisée, en dessous, couvre les tests de contrat, les tests de performance, la vérification de sécurité et les SBOM.

04 Points d’attention et limites

Choix d’ingénierie et limites

  • Le monolithe modulaire d’abord

    Notre méthode

    Nous commençons par des modules clairement délimités dans une seule unité déployable, et n’en extrayons des services que lorsque la montée en charge, le rythme de livraison ou la responsabilité des équipes l’exigent.

    Limites et dépendances

    Les microservices résolvent des problèmes d’organisation autant que des problèmes techniques. Sans équipes pour les porter, ils ajoutent des coûts et des modes de défaillance.

  • L’accessibilité est un travail d’ingénierie

    Notre méthode

    Des composants accessibles, des contrôles automatisés dans la chaîne CI/CD et des tests manuels avec des technologies d’assistance avant chaque version majeure.

    Limites et dépendances

    Les outils automatisés ne détectent qu’une partie des problèmes. Une conformité complète exige des audits manuels et, idéalement, des tests avec des personnes en situation de handicap.

    Les contenus et documents ajoutés par les contributeurs après le lancement doivent respecter le même niveau d’exigence. Nous formons les contributeurs, mais nous ne maîtrisons pas ce qu’ils publient.

  • La modernisation avance au rythme des données

    Notre méthode

    La migration des données est planifiée par fonctionnalité, répétée et rapprochée, avec une validation métier à chaque bascule.

    Limites et dépendances

    La qualité des données existantes fixe souvent le rythme. Leur nettoyage est une tâche métier autant que technique.

  • La réglementation des produits logiciels

    Notre méthode

    Les SBOM, la gestion des vulnérabilités et la sécurité par défaut font partie de notre chaîne standard, ce qui prépare les produits au Cyber Resilience Act.

    Limites et dépendances

    Savoir si et comment le règlement s’applique à votre produit est une question juridique. Nous fournissons les éléments de preuve techniques ; vos conseils réalisent l’analyse.

05 Notre façon de travailler

Notre façon de travailler

Des cycles courts, de vrais utilisateurs très tôt, et une passation planifiée dès la première semaine.

  1. 01

    Cartographier le domaine

    Un event storming avec les personnes qui connaissent les règles, et une cartographie des fonctionnalités existantes.

    LivrableCarte des contextes et premiers dossiers de décision

  2. 02

    Livrer une première tranche verticale

    Une fonctionnalité de bout en bout, à travers la façade, en production avec de vrais utilisateurs.

    LivrableTranche opérationnelle en production

  3. 03

    Étendre fonctionnalité par fonctionnalité

    Chaque version migre une fonctionnalité, ses données et ses utilisateurs, avec rapprochement et retour arrière prêts.

    LivrablePlan de livraison par fonctionnalité

  4. 04

    Assurer la passation

    Vos développeurs travaillent en binôme avec les nôtres, reprennent l’astreinte et pilotent la feuille de route dès que les critères de passation sont remplis.

    LivrablePassation validée

06 Contrôle humain

Là où l’humain garde la main

Dans un logiciel métier, garder le contrôle, c’est savoir qui a modifié quoi, qui l’a approuvé et comment revenir en arrière.

  • Les product owners décident du périmètre

    Votre product owner fixe les priorités et accepte chaque incrément. Nous conseillons, il décide.

  • Le paramétrage a un responsable

    Les paramètres des locataires et les feature flags sont modifiés selon un processus audité, par les rôles que vous désignez.

  • Les bascules sont approuvées

    Chaque passage de l’ancien au nouveau système est validé par le métier, avec une procédure de retour arrière testée au préalable.

  • Les décisions sont consignées

    Les dossiers de décision d’architecture montrent ce qui a été choisi, par qui et pourquoi, pour que les équipes futures puissent les réexaminer en connaissance de cause.

07 Technologies

Technologies que nous utilisons

Back-end
  • Java et Kotlin
  • .NET
  • TypeScript et Node.js
  • Python
Front-end
  • React et Next.js
  • Angular
  • Design systems aux composants accessibles
  • Mobile natif et multiplateforme
Données
  • PostgreSQL
  • SQL Server et Oracle (environnements existants)
  • Streaming d’événements
  • Moteurs de recherche
Qualité et sécurité
  • Playwright et tests de contrat
  • Tests de charge et de performance
  • SAST, DAST et analyse des dépendances
  • SBOM au format CycloneDX ou SPDX

La mention d’une technologie décrit notre expérience d’ingénierie. Elle n’implique ni partenariat avec son éditeur ni recommandation de sa part.

08 Exemple

Un exemple illustratif

Exemple illustratif

Un portail adhérents conforme au RGAA

01Situation
Une mutuelle doit refondre son portail adhérents : audit RGAA défavorable, demandes de remboursement abandonnées en cours de parcours, application mobile développée séparément.
02Ce que nous construirions
Un portail unique et adaptatif, relié au système de gestion par des API, construit sur des composants accessibles réutilisables et une authentification forte.
03Là où l’humain décide
Chaque version passe un audit RGAA avant publication ; les non-conformités restantes figurent dans la déclaration d’accessibilité avec leur échéance de correction.
04Ce que nous mesurerions
Taux de conformité RGAA par version, taux d’achèvement des demandes en ligne, appels évités au centre de contact.

09 Regard sectoriel

Dans votre secteur

  • Secteur public et administrations

    Gestion de dossiers et portails citoyens conformes aux obligations légales d’accessibilité, disponibles dans chaque langue officielle et connectés aux plateformes nationales d’échange de données.

  • Services financiers

    Portails clients et applications de back-office avec des pistes d’audit solides et des processus de livraison qui satisfont aux exigences de gestion des changements.

  • Industrie manufacturière

    Configurateurs, portails de service et produits SaaS pour les fabricants d’équipements, connectés à l’ERP et au service terrain.

France

Accessibilité, sécurité et maintenabilité

Un service numérique proposé en France doit démontrer son accessibilité selon le RGAA 4.1 et publier une déclaration d’accessibilité. Depuis juin 2025, la directive européenne sur l’accessibilité (European Accessibility Act) s’applique en outre à de nombreux produits et services destinés aux consommateurs, et le Cyber Resilience Act introduit par étapes des obligations de sécurité pour les logiciels commercialisés.

Nous intégrons ces exigences à la chaîne de livraison : audits RGAA outillés et manuels, déclaration tenue à jour, nomenclature logicielle (SBOM) et gestion des vulnérabilités, documentation en français prête pour un DCE ou un audit.

Questions sur les logiciels métier et le SaaS

Faut-il développer sur mesure ou paramétrer une plateforme ?

Paramétrez une plateforme lorsque votre processus est proche du standard, et développez sur mesure lorsque le processus vous distingue ou qu’aucune plateforme ne correspond aux règles. Nous travaillons avec Salesforce, SAP et Odoo comme en développement spécifique : nous n’avons donc aucune raison d’imposer une réponse. Notre accompagnement en architecture et conseil rend ce choix explicite.

Pouvez-vous garantir que notre portail sera accessible ?

Nous développons selon la norme EN 301 549 et les WCAG 2.2 AA, testons de manière automatisée et manuelle, et livrons un rapport de conformité mentionnant les éventuels problèmes connus. Nous ne promettons pas zéro défaut ; nous nous engageons à les détecter, à les signaler et à corriger ce qui relève de notre périmètre.

Pouvez-vous moderniser sans migration en « big bang » ?

Oui, et c’est ce que nous recommandons. Une façade de routage nous permet de migrer une fonctionnalité à la fois pendant que l’application existante continue de fonctionner, avec des données rapprochées à chaque étape.

Notre propre équipe peut-elle reprendre le logiciel ?

C’est le plan par défaut. Les critères de passation sont convenus au départ, vos développeurs travaillent en binôme avec les nôtres pendant la réalisation, et les dossiers de décision comme les procédures d’exploitation sont conservés dans vos dépôts.

Que change le Cyber Resilience Act pour notre produit ?

Si vous mettez sur le marché de l’UE un logiciel comportant des éléments numériques, le règlement peut entraîner des obligations en matière de conception sécurisée, de gestion des vulnérabilités et de documentation. Nous produisons les éléments de preuve techniques : SBOM, processus de gestion des vulnérabilités et sécurité par défaut. L’analyse juridique reste du ressort de vos conseils.

Parlons de votre application

Que vous partiez d’un cahier des charges, d’un produit existant ou d’une application vieillissante, nous commençons par les utilisateurs, l’accessibilité et la question de la maintenance.

Échanger sur votre projetDécouvrir notre approche