Aller au contenu principal
FromNine
Menu

Ingénierie

Un socle cloud qui fait de chaque mise en production une routine.

Environnements décrits en code, livraisons signées et reproductibles, un responsable pour chaque euro dépensé : c’est ainsi que nous bâtissons socles cloud et plateformes internes pour développeurs.

Pour les groupes qui exploitent un même socle cloud pour des entités au Luxembourg et dans d’autres États membres, chacune face à son autorité.

Parler de votre projetVoir l’architecture de référence
Ingénierie cloud et plateformes : les briquesQuatre couches superposées. En haut, les applications des équipes produit ; en dessous, la plateforme interne pour développeurs ; puis les chaînes de livraison signées ; à la base, la landing zone qui porte identités, réseau et règles.01Applications des équipes produit02Plateforme interne pour développeurs03Chaînes de livraison signées04Landing zone et règles
  1. 01Landing zones régies par des règles en code, avec un lieu d’hébergement des données défini application par application
  2. 02Des golden paths qui mènent un nouveau service en production toujours de la même façon
  3. 03SLO, reprise testée et coût par produit, sous les yeux de ceux qui décident

01 Problèmes

Quand le socle vous freine

  1. 01

    Chaque environnement est un cas à part

    Entre recette et production, des écarts que personne n’a documentés ; et les corrections faites à la main dans la console s’effacent à la prochaine reconstruction.

  2. 02

    Pas de livraison sans réunion

    Peu de déploiements, faits à la main, en soirée. Les équipes accumulent les changements, et chaque livraison en devient plus risquée.

  3. 03

    La facture cloud surprend tout le monde

    On voit les coûts par abonnement, pas par produit. Les GPU destinés à l’IA reviennent à qui les a demandés en premier.

  4. 04

    Personne ne sait si la reprise fonctionne

    Des sauvegardes existent. Aucune restauration n’a jamais été essayée, et ni la durée d’interruption tolérée ni la perte de données acceptable n’ont été arrêtées avec les métiers.

02 Prestations

Nos prestations

  1. 01 Landing zones et options de souveraineté

    Organisation des comptes et abonnements, identités, réseau et garde-fous, chez les grands hyperscalers comme sur les offres de cloud souverain européennes. Les règles sont écrites en code, et le lieu d’hébergement des données se fixe pour chaque application.

    Ce que nous faisons

    • Conception de l’organisation, des groupes de gestion et des comptes
    • Réseau en étoile, maîtrise des flux sortants et liaisons privées
    • Règles en code pour la localisation, le chiffrement et l’étiquetage
    • Correspondance avec les attestations que réclament vos clients, comme BSI C5 lorsqu’ils sont établis en Allemagne

    Ce que vous recevez

    • Landing zone intégralement décrite en code
    • Bibliothèque de règles avec procédure de dérogation
    • Note sur les options de souveraineté par catégorie d’application

  2. 02 Infrastructure en code et plateformes internes

    Terraform ou OpenTofu et Bicep pour l’infrastructure, GitOps pour déployer, Kubernetes ou un environnement d’exécution géré selon le besoin. Grâce aux golden paths, une équipe démarre un service conforme sans passer par un ticket.

    Ce que nous faisons

    • Bibliothèque de modules d’infrastructure en code
    • GitOps et promotion d’un environnement à l’autre
    • Plateforme Kubernetes ou alternatives gérées
    • Modèles de service et portail développeurs

    Ce que vous recevez

    • Plateforme interne dotée de golden paths
    • Environnements en libre-service
    • Feuille de route portée par une équipe plateforme

  3. 03 Chaînes de livraison et sécurité de la chaîne logicielle

    Chaque artefact est construit une seule fois, signé, accompagné d’une provenance conforme à SLSA, puis promu tel quel de la recette à la production ; les secrets sont gérés dans un coffre dédié.

    Ce que nous faisons

    • Modèles de chaîne avec contrôles de qualité et de sécurité
    • Signature des artefacts et attestation de provenance
    • Gestion des secrets et rotation des clés
    • Règles de promotion et traçabilité des changements

    Ce que vous recevez

    • Modèles de chaîne réutilisables
    • Artefacts signés dont la provenance se vérifie
    • Preuves de livraison pour la gestion des changements

  4. 04 Observabilité et SRE

    Objectifs de niveau de service fixés avec les métiers, budgets d’erreur qui dictent la cadence des livraisons, OpenTelemetry d’un bout à l’autre de la pile, et un processus d’incident qui sert aussi les notifications NIS2 et DORA quand elles s’appliquent à vous.

    Ce que nous faisons

    • Définition des SLO avec les responsables de service
    • Instrumentation OpenTelemetry et tableaux de bord
    • Alertes sur les symptômes plutôt que sur les causes
    • Gestion des incidents et retours d’expérience

    Ce que vous recevez

    • Catalogue de SLO
    • Outillage d’observabilité et tableaux de bord
    • Procédures d’incident et de notification

  5. 05 FinOps et capacité pour l’IA

    Coûts ventilés par produit et par équipe, indicateurs unitaires tels que le coût d’une transaction, et capacité GPU planifiée et maîtrisée pour l’IA.

    Ce que nous faisons

    • Règles d’étiquetage et modèle de répartition
    • Coût unitaire par produit
    • Planification des engagements et réservations
    • Ordonnancement GPU, quotas et dimensionnement au plus juste

    Ce que vous recevez

    • Tableaux de bord de coûts pour chaque product owner
    • Liste d’économies avec un responsable pour chacune
    • Plan de capacité pour l’IA

  6. 06 Reprise et réversibilité

    Sauvegardes et reprise après sinistre, avec des objectifs de reprise (RTO, RPO) chiffrés et testés à intervalles réguliers, plus une stratégie de sortie qui s’appuie sur le droit de changer de fournisseur ouvert par le règlement européen sur les données.

    Ce que nous faisons

    • RTO et RPO convenus pour chaque service
    • Essais de restauration et de bascule
    • Cartographie des dépendances des services critiques
    • Plan de sortie et vérification de la portabilité des données

    Ce que vous recevez

    • Procédures de reprise testées
    • Comptes rendus d’essais de reprise
    • Stratégie de sortie documentée

03 Architecture

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

Le code arrive d’un côté, les applications tournent de l’autre. Au milieu, tout ce qui est construit est signé, le registre refuse les artefacts non signés, et un contrôleur GitOps les promeut d’un environnement au suivant dans le respect des règles.

Au fond se trouve la landing zone, écrite une fois en code et commune à toutes les équipes : organisation, identités, réseau, clés, reprise et maîtrise des coûts.

Couches du schéma

Livraison
Dépôts, chaînes, artefacts signés et promotion GitOps.
Plateforme
La plateforme développeurs, les règles en code et l’environnement d’exécution des équipes produit.
Landing zone
Organisation, identités, réseau, clés, reprise et maîtrise FinOps.
Exploitation
Télémétrie, SLO, budgets d’erreur et réponse aux incidents sur l’ensemble.
Exemple illustratif

  1. Livraison

    • Dépôts de code et d’IaC
    • Construire, signer, attester
    • Registre d’artefacts signés
    • Promotion GitOps

  2. Plateforme

    • Plateforme développeurs et golden paths
    • Règles en code
    • Kubernetes et services gérés
    • Applications des équipes produit

  3. Landing zone

    • Structure de gestion
    • Identités et accès
    • Réseau central et flux sortants
    • Clés et secrets
    • Sauvegarde et reprise
    • Répartition des coûts

  4. Exploitation

    • OpenTelemetry, SLO et budgets d’erreur, réponse aux incidents
Livraison signée sur une landing zone gouvernée par des règles

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

Lire le schéma sous forme de texte

Sur le chemin principal, le code et l’infrastructure quittent leurs dépôts, passent par des chaînes qui les construisent, les signent et en attestent l’origine, entrent dans un registre d’artefacts, puis un contrôleur GitOps les déploie dans les espaces de chaque équipe produit.

Une plateforme interne offre des golden paths vers les chaînes. Des règles en code encadrent le contrôleur GitOps. Une plateforme d’exécution, Kubernetes et services gérés, héberge les applications. Des clés gérées par le client alimentent la couche de règles.

Sous l’ensemble, la landing zone regroupe structure de gestion, identités et droits d’accès, réseau central, clés, sauvegardes et reprise, ainsi que le pilotage FinOps. L’observabilité, avec ses SLO et la gestion des incidents, s’étend à toute la plateforme.

04 Choix et limites

Choix techniques et limites

  • La souveraineté a plusieurs degrés

    Notre approche

    Nous classons les applications selon leur sensibilité et associons chaque classe à une option : régions UE d’un hyperscaler, offre de cloud souverain ou infrastructure privée. Les compromis sur les fonctions, le coût et l’exploitation sont mis par écrit.

    Limites et dépendances

    Les offres souveraines proposent souvent moins de services gérés, y compris pour l’IA. Certaines applications y coûteront plus ou feront moins : c’est un choix métier.

  • Une plateforme a besoin d’un product owner

    Notre approche

    La plateforme interne est gérée comme un produit : des utilisateurs, une feuille de route, des retours réguliers. Nous vous aidons aussi à monter l’équipe qui l’exploite.

    Limites et dépendances

    Une plateforme sans équipe finit en goulet d’étranglement. Faute de pouvoir l’équiper, mieux vaut des services gérés et moins d’abstraction : c’est ce que nous recommanderons.

  • La réglementation façonne l’exploitation

    Notre approche

    Lorsque NIS2 ou DORA vous concernent, la classification des incidents, les délais de notification et la collecte des preuves sont intégrés au processus d’incident. Au Luxembourg, un incident important se notifie dans les 24 heures à l’autorité compétente, l’ILR pour la plupart des secteurs ; les entités financières supervisées par la CSSF déclarent leurs incidents DORA via son eDesk.

    Limites et dépendances

    Savoir si vous entrez dans le champ de ces textes, et comment la loi luxembourgeoise s’applique à vous, reste du ressort de vos équipes conformité et juridique.

  • La maîtrise des coûts est partagée

    Notre approche

    Nous rendons le coût visible par produit et ajoutons des garde-fous : budgets, quotas, arrêt programmé des environnements inutilisés.

    Limites et dépendances

    Les économies les plus importantes viennent en général de choix d’architecture et d’usage faits par les product owners, pas de la plateforme seule.

05 Méthode

Notre méthode

D’abord le socle, puis une équipe sur le golden path, puis toutes les autres.

  1. 01

    Évaluer et classer

    Applications, sensibilité des données, coûts actuels et contrôles attendus par vos auditeurs.

    LivrableClassement des applications et options cibles

  2. 02

    Construire la landing zone

    Tout en code, revu avec la sécurité, avec une procédure pour les dérogations.

    LivrableLanding zone en production

  3. 03

    Embarquer une équipe pionnière

    Une équipe produit passe sur le golden path ; ses difficultés orientent la plateforme.

    LivrablePremier service sur la plateforme

  4. 04

    Étendre et transférer

    Les autres équipes suivent, l’équipe plateforme reprend la main, et des essais de reprise ont lieu à dates fixes.

    LivrableFeuille de route de la plateforme et comptes rendus d’essais de reprise

06 Contrôle humain

Là où les personnes gardent la main

L’automatisation fait tourner la plateforme. Les décisions qui comportent un risque ou un coût restent aux mains de personnes.

  • Chaque changement en production est traçable

    Toute modification de la production provient d’un commit relu : qui a changé quoi et qui l’a approuvé reste toujours enregistré.

  • L’accès d’urgence reste exceptionnel et journalisé

    Limité dans le temps, justifié à chaque fois, revu après coup.

  • Chaque dérogation a un responsable

    Si une application doit déroger à un garde-fou, un responsable des risques nommé donne son accord, pour une durée limitée.

  • Les responsables de service fixent les objectifs

    Ce sont les responsables métier de chaque service qui conviennent des objectifs de reprise et des niveaux de service, et non l’équipe plateforme de son côté.

07 Technologies

Technologies que nous utilisons

Cloud
  • Microsoft Azure
  • Amazon Web Services
  • Google Cloud
  • Offres de cloud souverain européennes
Infrastructure et livraison
  • Terraform et OpenTofu
  • Bicep
  • Argo CD et Flux
  • GitHub Actions, GitLab CI et Azure DevOps
Exécution
  • Kubernetes et ses variantes gérées
  • Plateformes serverless et conteneurs
  • Service mesh lorsqu’il se justifie
  • Pools de nœuds GPU pour l’IA
Exploitation
  • OpenTelemetry
  • Prometheus et Grafana
  • Supervision native du cloud
  • Moteurs de règles comme OPA

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

Une landing zone commune pour un groupe logistique présent dans trois pays

01Situation
Un groupe de transport et de logistique a des filiales au Luxembourg, en Belgique et en France, chacune avec son propre tenant cloud et ses propres contrôles. Chaque autorité nationale attend les notifications d’incident NIS2 selon ses règles, l’ILR dans les 24 heures pour l’entité luxembourgeoise, et personne ne peut présenter la sécurité du groupe d’un seul coup d’œil.
02Ce que nous construirions
Une landing zone unique en code, avec des jeux de règles propres à chaque entité, une journalisation commune et un processus d’incident qui classe chaque événement et oriente la notification vers l’autorité du bon pays.
03Où les personnes décident
Le responsable sécurité de chaque filiale approuve les dérogations pour ses applications ; le RSSI du groupe est responsable du socle commun.
04Ce que nous mesurerions
Délai entre la détection d’un incident et sa classification, part des applications couvertes par les règles et essais de reprise réussis par trimestre.

09 Par secteur

Selon votre secteur

  • État et communes

    Pour l’État, les communes et les établissements publics : options de souveraineté par catégorie de données, données hébergées dans l’UE et plans de sortie qui résistent au prochain marché public.

  • Secteur financier

    Pour les banques, assureurs et acteurs des fonds : résilience opérationnelle au sens de DORA, sous la supervision de la CSSF ou du CAA. Reprise testée, registre d’informations sur les prestataires TIC et notification des incidents intégrés à l’exploitation.

Luxembourg

Des preuves produites une fois, pour chaque autorité

NIS2 est une directive unique, mais chaque transposition nationale fixe son propre champ, son enregistrement et ses modalités de notification. Les entités financières y ajoutent DORA, avec ses notifications d’incident et sa surveillance des prestataires TIC. Un groupe présent dans plusieurs pays a besoin d’une plateforme capable de produire les preuves que chaque autorité demande.

Au Luxembourg, la loi du 5 mai 2026 transpose NIS2 depuis le 10 mai 2026. L’ILR est l’autorité compétente pour la plupart des secteurs ; il tient un portail d’enregistrement et attend la notification d’un incident dans les 24 heures. DORA s’applique depuis le 17 janvier 2025 : la CSSF et le CAA en sont les autorités compétentes, et les entités supervisées par la CSSF déclarent leurs incidents via son eDesk, selon la circulaire CSSF 25/893.

Nos landing zones traitent la localisation des données, la journalisation et la classification des incidents comme des règles, pas comme des projets : une nouvelle entité ou un nouveau pays s’ajoute par configuration. Les plans de sortie s’appuient sur les droits de changement de fournisseur du règlement européen sur les données, et ils sont testés, pas seulement rédigés.

Vos questions sur le cloud et les plateformes

Quel fournisseur cloud recommandez-vous ?

Celui qui convient à vos applications, à vos contrats en cours et à vos exigences de souveraineté. Nous travaillons avec les grands hyperscalers et avec les offres souveraines européennes, et nous documentons les compromis : le choix peut être défendu dans un marché public et réexaminé plus tard.

Avons-nous besoin de Kubernetes ?

Pas forcément. Kubernetes devient rentable avec beaucoup de services et une équipe dédiée à la plateforme. Avec quelques services seulement, des conteneurs gérés ou une offre serverless sont souvent plus simples et moins coûteux.

Quelle est votre approche de la sécurité ?

Elle fait partie de la landing zone et des chaînes de livraison dès le départ : droits minimaux pour chaque identité, règles écrites en code, artefacts signés, secrets tenus hors du code. Pour sa propre gestion de la sécurité de l’information, FromNine est certifiée ISO/IEC 27001.

Pouvez-vous réduire notre facture cloud ?

En général oui, mais aucun pourcentage n’est promis avant d’avoir vu les données. Nous commençons par rendre le coût visible par produit, puis nous traitons une liste d’économies avec les responsables qui peuvent agir.

Comment éviter la dépendance à un fournisseur ?

Décidez en connaissance de cause où vous acceptez un service propre à un fournisseur, gardez l’infrastructure sous forme de code et entretenez un plan de sortie écrit et éprouvé. Le règlement européen sur les données renforce votre droit de changer de fournisseur ; encore faut-il un plan pour l’exercer. Côté financier, ce même plan répond à ce que DORA attend d’une stratégie de sortie.

Montrez-nous vos trois prochaines livraisons

Nous vous dirons ce qui en ferait une routine, et ce que ce socle coûterait à construire puis à exploiter.

Parler de votre projetArchitecture et conseil