Aller au contenu principal
FromNine
Menu

Ingénierie

Un logiciel métier que vos équipes peuvent continuer à faire évoluer.

Produits SaaS, portails pour citoyens, investisseurs ou collaborateurs, applications au cœur de votre activité : nous les développons accessibles, sécurisés par défaut et maintenables par vos propres équipes bien après le lancement.

Pour les éditeurs de logiciels et les organismes publics dont les utilisateurs vivent dans plusieurs pays, lisent plusieurs langues et relèvent de plusieurs régimes juridiques.

Parler de votre projetModernisation applicative
Logiciels métier et SaaS : les briquesQuatre couches superposées. En surface, l’interface accessible qu’utilisent les personnes ; sous elle, les modules métier qui portent les règles ; ensuite les services de plateforme pour l’identité et la gestion multi-clients ; au fond, la chaîne de livraison sécurisée.01Interfaces accessibles02Modules et règles métier03Multi-clients, identité, données04Chaîne de livraison sécurisée
  1. 01Conception pilotée par le domaine pour les métiers chargés de règles, comme l’instruction de dossiers
  2. 02Accessibilité selon EN 301 549 et WCAG 2.2 AA dès la première maquette
  3. 03Documentation et registres de décisions que vos équipes reprennent sans peine

01 Problèmes

Ce que l’on nous dit avant une refonte

  1. 01

    Trois mois pour la moindre modification

    L’application tourne, mais plus personne n’ose toucher au noyau. Une petite évolution exige une longue campagne de non-régression et une fenêtre de mise en production.

  2. 02

    Le portail écarte une partie de son public

    Il ne fonctionne ni avec un lecteur d’écran, ni en allemand, ni sur un téléphone. Les plaintes précèdent l’audit d’accessibilité.

  3. 03

    Ce qu’un client demande casse ce qu’un autre utilise

    Le produit SaaS a grandi à coups d’adaptations par client. Chaque version se négocie désormais, et certains clients restent bloqués sur d’anciennes versions.

  4. 04

    Le savoir est parti avec le fournisseur

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

  5. 05

    Clients et autorités posent des questions de sécurité

    Un appel d’offres réclame une SBOM, un processus de gestion des vulnérabilités et des preuves pour le règlement sur la cyberrésilience. Rien n’est prêt.

02 Prestations

Nos prestations

  1. 01 Développement de produits SaaS

    Un seul code pour servir de nombreux clients : le modèle multi-clients adapté, du paramétrage plutôt que du spécifique, et des versions qui atteignent tous les clients.

    Ce que nous faisons

    • Choix du modèle multi-clients : partagé, mutualisé ou isolé par client
    • Stratégie de paramétrage et d’activation de fonctionnalités (feature flags)
    • Mesure de l’usage et lien avec la facturation
    • Trains de versions avec déploiement progressif selon le client

    Ce que vous recevez

    • Conception du cloisonnement entre clients
    • Modèle de paramétrage encadré par des garde-fous
    • Processus de livraison avec retour arrière client par client

  2. 02 Conception du domaine pour des règles complexes

    Le domain-driven design là où les règles font le produit : instruction de dossiers, conditions d’éligibilité, calculs encadrés par la réglementation. Entre monolithe modulaire et microservices, le choix est délibéré ; le plus souvent, nous commençons par le premier.

    Ce que nous faisons

    • Ateliers d’event storming avec les experts métier
    • Contextes délimités et frontières entre modules
    • Règles rendues explicites et vérifiables par des tests
    • Registres de décisions d’architecture pour les choix structurants

    Ce que vous recevez

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

  3. 03 Portails pour citoyens, clients et collaborateurs

    Des interfaces bâties sur un design system, accessibles d’emblée et multilingues dès la première version. Au Luxembourg, cela veut dire au moins le français et l’allemand, avec des contenus que vos rédacteurs peuvent aussi publier en luxembourgeois ou en anglais ; 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 de technologies d’assistance
    • Circuit de traduction pour chaque langue

    Ce que vous recevez

    • Portail reposant sur un design system réutilisable
    • Rapport de conformité en matière d’accessibilité
    • Circuit de rédaction et de traduction

  4. 04 Qualité logicielle et développement sécurisé

    Des tests automatisés aux bons niveaux, des tests de contrat entre services, des tests de charge avant le lancement, et un cycle de développement sécurisé qui s’appuie sur l’OWASP ASVS, les SBOM et le contrôle de la chaîne d’approvisionnement logicielle.

    Ce que nous faisons

    • Stratégie de test et automatisation
    • Tests de contrat et de performance
    • Modélisation des menaces et vérification ASVS
    • Production de SBOM et règles sur les dépendances

    Ce que vous recevez

    • Suites de tests automatisés dans la chaîne CI/CD
    • Rapport de vérification de sécurité
    • Gestion des vulnérabilités prête pour le règlement sur la cyberrésilience

  5. 05 Modernisation progressive

    L’application historique est remplacée fonction après fonction, derrière une façade de routage, sans arrêter l’activité. Voir aussi la modernisation d’applications historiques.

    Ce que nous faisons

    • Cartographie des fonctions de l’application existante
    • Routage selon le modèle strangler fig et encapsulation par API
    • Migration des données avec rapports de rapprochement
    • Fonctionnement en parallèle pour les calculs sensibles

    Ce que vous recevez

    • Séquence de modernisation jalonnée par des étapes métier
    • Façade et nouveaux modules en production
    • Données rapprochées à chaque bascule

  6. 06 Maintenabilité et transfert

    Un logiciel dont vos équipes peuvent prendre la responsabilité : code lisible, registres de décisions, procédures d’exploitation et plan de transfert arrêté dès le départ plutôt que découvert à la fin.

    Ce que nous faisons

    • Binômes avec vos développeurs pendant la réalisation
    • Registres de décisions conservés dans le dépôt de code
    • Procédures d’exploitation et guides d’astreinte
    • Jalons de transfert de connaissances

    Ce que vous recevez

    • Plan de transfert avec critères d’acceptation
    • Documentation rangée dans vos dépôts
    • Équipe interne formée

03 Architecture

Une architecture de référence, à titre d’illustration

Quand une application de gestion en remplace une plus ancienne, on retrouve souvent la même forme. Une interface accessible ; une façade qui envoie chaque fonction vers l’ancien ou le nouveau système ; une couche d’API aux contrats nets ; un noyau modulaire organisé selon le domaine.

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

Couches du schéma

Utilisateurs
Citoyens, clients et collaborateurs, sur tout appareil et avec leurs 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és, noyau modulaire, multi-clients et paramétrage, données opérationnelles.
Livraison sécurisée
Tests de contrat et de performance, contrôles ASVS et SBOM produits à 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és et rôles
    • Noyau modulaire : réception, dossiers, facturation
    • Multi-clients, 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 noyau modulaire derrière une façade de routage

Schéma d’illustration : il ne représente le système d’aucun client.

Lire le schéma sous forme de texte

Le chemin principal mène des utilisateurs à une interface accessible, puis traverse une façade de routage et une couche d’API pour atteindre un noyau modulaire découpé en contextes délimités.

Pour certaines fonctions, la façade renvoie encore vers l’application existante, retirée par étapes. Ses données rejoignent les bases opérationnelles par une migration avec rapprochement.

La gestion des identités sert la couche d’API. Sous le noyau se trouvent les services multi-clients et de paramétrage. Une bande de livraison sécurisée, tout en bas, regroupe tests de contrat et de performance, vérifications de sécurité et SBOM.

04 Choix et limites

Choix techniques et limites

  • D’abord un monolithe modulaire

    Notre approche

    Nous partons de modules bien séparés dans une seule unité déployable. Un service n’est extrait que lorsque la montée en charge, le rythme des versions ou la répartition des équipes l’exigent.

    Limites et dépendances

    Les microservices règlent autant des questions d’organisation que des questions techniques. Sans équipes pour les prendre en charge, ils ajoutent des coûts et de nouvelles pannes possibles.

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

    Notre approche

    Composants accessibles, contrôles automatiques dans la chaîne de livraison et tests manuels avec technologies d’assistance avant chaque version majeure.

    Limites et dépendances

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

    Les contenus et documents ajoutés par vos rédacteurs après le lancement doivent respecter la même exigence. Nous formons les rédacteurs, mais ce qu’ils publient reste sous votre contrôle.

  • Le rythme de la modernisation, c’est celui des données

    Notre approche

    La migration des données est planifiée fonction par fonction, répétée et rapprochée, avec l’accord des métiers à chaque bascule.

    Limites et dépendances

    La qualité des données historiques dicte souvent la cadence. Les assainir relève autant des métiers que de la technique.

  • La réglementation des produits logiciels

    Notre approche

    SBOM, gestion des vulnérabilités et paramètres sûrs par défaut font partie de notre chaîne standard, ce qui prépare vos produits au règlement sur la cyberrésilience.

    Limites et dépendances

    Savoir si ce règlement s’applique à votre produit, et comment, est une question juridique. Nous apportons les preuves techniques ; vos conseils font l’analyse.

05 Méthode

Notre méthode

Des cycles courts, de vrais utilisateurs dès le début, et un transfert préparé dès la première semaine.

  1. 01

    Cartographier le domaine

    Event storming avec celles et ceux qui connaissent les règles, et cartographie des fonctions existantes.

    LivrableCarte des contextes et premiers registres de décisions

  2. 02

    Livrer une première tranche fine

    Une fonction complète, de bout en bout, qui passe par la façade et arrive en production devant de vrais utilisateurs.

    LivrableTranche opérationnelle en production

  3. 03

    Avancer fonction par fonction

    Chaque version déplace une fonction, ses données et ses utilisateurs, avec rapprochement et retour arrière préparés.

    LivrablePlan de versions par fonction

  4. 04

    Transférer

    Vos développeurs travaillent avec les nôtres, reprennent l’astreinte puis la feuille de route une fois les critères de transfert remplis.

    LivrableTransfert accepté

06 Contrôle humain

Là où les personnes gardent la main

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

  • Le product owner fixe le périmètre

    Votre product owner définit les priorités et accepte chaque incrément. Nous conseillons ; la décision lui revient.

  • Le paramétrage a un responsable

    Les réglages par client et les feature flags se modifient via un processus tracé, par les rôles que vous désignez.

  • Chaque bascule est approuvée

    Tout passage de l’ancien au nouveau système est validé par les métiers, avec un retour arrière déjà répété.

  • Les décisions sont écrites

    Les registres de décisions d’architecture indiquent ce qui a été choisi, par qui et pourquoi, pour que les équipes suivantes puissent y revenir 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 (parcs existants)
  • Flux d’événements (event streaming)
  • 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

Une technologie citée ici reflète notre expérience d’ingénierie. Elle ne signifie ni partenariat avec son éditeur ni recommandation de sa part.

08 Exemple

Un exemple illustratif

Exemple illustratif

Un portail investisseurs en trois langues pour un gestionnaire de fonds

01Situation
Un gestionnaire de fonds établi au Luxembourg sert des investisseurs en France, en Allemagne et au-delà. Trois portails construits à des époques différentes coexistent, chacun avec ses propres défauts d’accessibilité, et chaque évolution doit être faite trois fois.
02Ce que nous construirions
Un portail unique sur un design system partagé, en français, en allemand et en anglais, où contenus, langues et intégrations propres à chaque marché sont gérés par paramétrage, avec un seul train de versions.
03Où les personnes décident
Les équipes de chaque marché valident contenus et paramétrage ; le product owner tranche sur les fonctions communes.
04Ce que nous mesurerions
Problèmes d’accessibilité par version, délai d’une évolution sur tous les marchés et part des évolutions réalisées une seule fois plutôt que par marché.

09 Par secteur

Selon votre secteur

  • État et communes

    Pour l’État et les communes : gestion des dossiers et portails conformes à la loi du 28 mai 2019 sur l’accessibilité (RAWeb), en français et en allemand, capables de recevoir les démarches déposées sur MyGuichet.lu.

  • Secteur financier

    Pour les banques, gestionnaires de fonds et assureurs : portails clients et investisseurs, applications de back-office avec pistes d’audit solides et mises en production conformes à votre gestion des changements.

  • Industrie

    Configurateurs, portails de service et produits SaaS pour les fabricants d’équipements, reliés à l’ERP et aux interventions sur le terrain.

Luxembourg

Un nouveau marché, c’est une version, pas une copie

Un produit vendu dans l’Union rencontre l’acte européen sur l’accessibilité à travers des lois nationales qui diffèrent dans le détail, et le règlement sur la cyberrésilience à travers un texte unique dont les obligations s’appliquent par étapes. Dans chaque pays, les clients attendent aussi leur langue, leurs règles de facturation et leurs moyens d’identification.

Au Luxembourg, la loi modifiée du 8 mars 2023 exige depuis le 28 juin 2025 des produits et services conformes, sous la surveillance de l’OSAPS. Pour les sites et applications des organismes publics, la loi du 28 mai 2019 s’applique, avec RAWeb et RAAM comme référentiels. Côté identification, MyGuichet.lu accepte LuxTrust, la carte d’identité électronique et les moyens eIDAS notifiés.

Ces écarts restent chez nous dans le paramétrage et dans des modules bien délimités : un nouveau marché devient une version, pas une branche à part. Les preuves d’accessibilité et la documentation de sécurité sortent de la chaîne de livraison, prêtes pour les questions que pose chaque appel d’offres.

Vos questions sur le logiciel métier et le SaaS

Développer sur mesure ou paramétrer une plateforme ?

Paramétrez une plateforme quand votre processus est proche du standard ; développez quand le processus fait votre différence ou qu’aucune plateforme ne gère vos règles. Nous travaillons avec Salesforce, SAP et Odoo autant qu’en sur mesure : nous n’avons aucune raison de pousser une réponse plutôt qu’une autre. Notre service Architecture et conseil rend ce choix explicite.

Pouvez-vous garantir l’accessibilité de notre portail ?

Nous développons selon EN 301 549 et WCAG 2.2 AA, nous testons de façon automatique et manuelle, et nous remettons un rapport de conformité qui liste les problèmes connus. Nous ne promettons pas l’absence totale de défaut ; nous promettons de les trouver, de les signaler et de corriger ce qui relève de notre périmètre. Pour un organisme public au Luxembourg, nous le structurons selon le référentiel RAWeb.

Est-il possible de moderniser sans tout basculer d’un coup ?

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

Notre équipe pourra-t-elle reprendre le logiciel ?

C’est le scénario prévu par défaut. Les critères de transfert sont fixés au départ, vos développeurs travaillent en binôme avec les nôtres pendant la réalisation, et registres de décisions et procédures d’exploitation sont rangés dans vos dépôts.

Que change le règlement sur la cyberrésilience pour notre produit ?

Si vous mettez sur le marché européen un logiciel comportant des éléments numériques, il peut créer des obligations de conception sécurisée, de gestion des vulnérabilités et de documentation. Nous construisons les preuves techniques : SBOM, processus de vulnérabilités, paramètres sûrs par défaut.

Dites-nous ce qui doit tourner pendant que tout change

Nous proposerons la première fonction à déplacer et ce dont votre équipe aura la responsabilité à la fin.

Parler de votre projetModernisation applicative