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 de logiciels, entreprises et administrations belges qui servent leurs utilisateurs en français, en néerlandais et en allemand.

É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 guichet électronique pour plusieurs communes

01Situation
Plusieurs communes wallonnes partagent une intercommunale informatique. Chacune propose ses propres formulaires en ligne, peu accessibles, et les citoyens doivent encore se déplacer pour des démarches simples.
02Ce que nous construirions
Un guichet électronique commun, connecté via le Service fédéral d’authentification, avec des démarches paramétrées par commune et l’envoi des documents vers l’eBox du citoyen.
03Là où l’humain décide
Chaque commune valide ses démarches et ses contenus avant publication ; l’intercommunale décide des évolutions communes.
04Ce que nous mesurerions
Part des démarches réalisées en ligne, anomalies d’accessibilité par version et délai de mise en ligne d’une nouvelle démarche.

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.

Belgique

Un logiciel, trois langues, plusieurs Régions

Un logiciel utilisé en Belgique doit souvent fonctionner dans les trois langues nationales et respecter des règles qui varient d’une Région à l’autre. Les services en ligne destinés aux consommateurs relèvent de la directive européenne sur l’accessibilité (European Accessibility Act), transposée en droit belge, et les sites des organismes publics de la directive sur l’accessibilité du web.

Nous intégrons dès la conception la connexion via le Service fédéral d’authentification, l’eID et itsme, ainsi que la facturation Peppol. Le Cyber Resilience Act s’ajoute pour les produits logiciels commercialisés.

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.

Dites-nous ce qui doit continuer à tourner pendant le changement

Nous vous proposons la première fonctionnalité à faire évoluer et ce que votre équipe maîtrisera à la fin, avec un code et une documentation qui vous appartiennent.

Demander un premier entretienDécouvrir notre approche