Aller au contenu principal
FromNine
Menu

Ingénierie

Ingénierie cloud et plateformes : des mises en production devenues routinières

Nous construisons des fondations cloud et des plateformes internes de développement où les environnements sont décrits en code, où les livraisons sont signées et reproductibles, et où chaque euro dépensé a un responsable.

Pour les DSI qui arbitrent entre hyperscaler, cloud de confiance et hébergement interne, et veulent pouvoir justifier chaque choix devant leur RSSI.

Échanger sur votre projetDécouvrir notre approche
Ingénierie cloud et plateformes : les couches de la solutionQuatre couches superposées en profondeur. De haut en bas : les charges de travail des équipes produit, la plateforme interne de développement, les chaînes de livraison signées, et à la base la zone d’atterrissage avec l’identité, le réseau et les règles.01Charges de travail des équipes produit02Plateforme interne de développement03Chaînes de livraison signées04Zone d’atterrissage et règles
  1. 01Des zones d’atterrissage avec policy as code et localisation des données définie par charge de travail
  2. 02Des chemins balisés (golden paths) qui mènent un nouveau service en production de façon reproductible
  3. 03Des SLO, une reprise testée et un coût par produit, visibles par les décideurs

01 Enjeux

Les signes que vos fondations vous freinent

  1. 01

    Chaque environnement est un cas particulier

    Recette et production diffèrent sur des points que personne n’a consignés, et les corrections faites à la main dans la console disparaissent à la reconstruction suivante.

  2. 02

    Une mise en production exige une réunion

    Les déploiements sont rares, manuels et programmés le soir. Les équipes regroupent les changements, ce qui rend chaque livraison plus risquée.

  3. 03

    La facture cloud surprend tout le monde

    Les coûts sont visibles par abonnement, pas par produit. La capacité GPU pour les travaux d’IA revient au premier qui l’a demandée.

  4. 04

    Personne ne sait si la reprise fonctionne

    Les sauvegardes existent. Les restaurations n’ont pas été testées, et les objectifs de délai de reprise et de perte de données n’ont jamais été convenus avec le métier.

02 Prestations

Ce que nous livrons

  1. 01 Zones d’atterrissage et options de souveraineté

    Structure des comptes et abonnements, identité, réseau et garde-fous sur les principaux hyperscalers et sur les offres de cloud souverain européennes, avec policy as code et localisation des données par charge de travail.

    Ce que nous faisons

    • Conception de l’organisation, des groupes d’administration et des comptes
    • Réseau en étoile (hub and spoke), contrôle des flux sortants et connectivité privée
    • Policy as code pour la localisation, le chiffrement et l’étiquetage
    • Correspondance avec les référentiels demandés par vos acheteurs, comme BSI C5 ou SecNumCloud

    Ce que vous recevez

    • Zone d’atterrissage entièrement décrite en code
    • Bibliothèque de règles avec processus de dérogation
    • Note d’options de souveraineté par classe de charge de travail

  2. 02 Infrastructure as code et plateformes internes de développement

    Terraform ou OpenTofu et Bicep pour l’infrastructure, GitOps pour les déploiements, Kubernetes ou des environnements d’exécution managés là où ils sont pertinents, et des chemins balisés pour qu’une équipe lance un service conforme sans ouvrir de tickets.

    Ce que nous faisons

    • Bibliothèque de modules d’infrastructure as code
    • GitOps avec promotion entre environnements
    • Plateforme Kubernetes ou alternatives managées
    • Modèles de services et portail développeurs

    Ce que vous recevez

    • Plateforme interne de développement avec chemins balisés
    • Environnements en libre-service
    • Feuille de route de la plateforme portée par une équipe plateforme

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

    Des chaînes qui construisent une seule fois, signent les artefacts, enregistrent leur provenance selon SLSA, gèrent correctement les secrets et promeuvent le même artefact de la recette à la production.

    Ce que nous faisons

    • Modèles de chaînes 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înes réutilisables
    • Artefacts signés à la provenance vérifiable
    • Preuves de livraison pour la gestion des changements

  4. 04 Observabilité et SRE

    Des objectifs de niveau de service convenus avec le métier, des budgets d’erreur qui règlent le rythme des livraisons, OpenTelemetry sur l’ensemble de la pile et un processus de gestion des incidents qui sert aussi les obligations de notification NIS2 et DORA lorsqu’elles s’appliquent.

    Ce que nous faisons

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

    Ce que vous recevez

    • Catalogue de SLO
    • Pile d’observabilité et tableaux de bord
    • Procédures de gestion et de notification des incidents

  5. 05 FinOps et capacité pour l’IA

    Répartition des coûts par produit et par équipe, coûts unitaires (par exemple le coût par transaction), planification de la capacité GPU et maîtrise de son coût pour les charges de travail d’IA.

    Ce que nous faisons

    • Politique d’étiquetage et modèle de répartition
    • Indicateurs de coût unitaire par produit
    • Planification des engagements et réservations
    • Ordonnancement GPU, quotas et dimensionnement au juste besoin

    Ce que vous recevez

    • Tableaux de bord des coûts par responsable produit
    • Backlog d’économies avec responsables
    • Plan de capacité pour l’IA

  6. 06 Reprise et réversibilité

    Sauvegarde et reprise après sinistre avec des objectifs explicites de délai et de point de reprise, testées à intervalles réguliers, et une stratégie de sortie qui s’appuie sur les droits de changement de fournisseur prévus par le règlement européen sur les données (Data Act).

    Ce que nous faisons

    • RTO et RPO convenus par service
    • Tests de restauration et de bascule
    • Cartographie des dépendances des services critiques
    • Plan de sortie et vérifications de portabilité des données

    Ce que vous recevez

    • Procédures de reprise testées
    • Rapports de tests de reprise
    • Stratégie de réversibilité documentée

03 Architecture

Une architecture de référence illustrative

Le code entre à gauche, les charges de travail en exécution sortent à droite. Entre les deux, la chaîne signe ce qu’elle construit, le registre ne stocke que des artefacts signés, et un contrôleur GitOps les promeut d’un environnement à l’autre sous le contrôle des règles.

En dessous se trouve la zone d’atterrissage : structure organisationnelle, identité, réseau, clés, reprise et maîtrise des coûts, définis une fois en code et partagés par toutes les équipes produit.

Couches du schéma

Livraison
Dépôts, chaînes CI/CD, artefacts signés et promotion GitOps.
Plateforme
La plateforme de développement, la policy as code et l’environnement d’exécution sur lequel déploient les équipes produit.
Zone d’atterrissage
Organisation, identité, réseau, clés, reprise et contrôles 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 de développement et chemins balisés
    • Policy as code
    • Kubernetes et services managés
    • Charges de travail des équipes produit

  3. Zone d’atterrissage

    • Structure d’administration
    • Identité et accès
    • Hub réseau 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
Une livraison signée sur une zone d’atterrissage régie par des règles

Architecture illustrative, pas un système client.

Lire le schéma sous forme de texte

Le parcours principal part des dépôts de code et d’infrastructure, passe par des chaînes qui construisent, signent et attestent, puis par un registre d’artefacts et un contrôleur GitOps, pour aboutir aux espaces de charges de travail des équipes produit.

Une plateforme interne de développement fournit des chemins balisés vers les chaînes. La policy as code encadre le contrôleur GitOps. Une plateforme d’exécution avec Kubernetes et des services managés héberge les charges de travail. Des clés gérées par le client alimentent la couche de règles.

La zone d’atterrissage, en dessous, comprend la structure d’administration, l’identité et les accès, un hub réseau, les clés, la sauvegarde et la reprise, ainsi que les contrôles FinOps. L’observabilité avec SLO et réponse aux incidents couvre toute la plateforme.

04 Points d’attention et limites

Choix d’ingénierie et limites

  • La souveraineté est une question de degré

    Notre méthode

    Nous classons les charges de travail selon leur sensibilité et associons chaque classe à une option : régions européennes d’un hyperscaler, offre de cloud souverain ou infrastructure privée. Les compromis (fonctionnalités, coût, exploitation) sont consignés par écrit.

    Limites et dépendances

    Les offres souveraines ont souvent un temps de retard en services managés, y compris en services d’IA. Certaines charges de travail y coûteront plus cher ou offriront moins, et c’est un choix métier.

  • Une plateforme a besoin d’un product owner

    Notre méthode

    Nous traitons la plateforme interne comme un produit, avec des utilisateurs, une feuille de route et des boucles de retour, et nous vous aidons à constituer l’équipe qui l’exploite.

    Limites et dépendances

    Une plateforme sans équipe devient un goulet d’étranglement. Si vous ne pouvez pas lui affecter une équipe, nous recommanderons des services managés et moins d’abstractions.

  • La réglementation façonne l’exploitation

    Notre méthode

    La classification des incidents, les délais de notification et la collecte de preuves sont intégrés au processus de gestion des incidents lorsque NIS2 ou DORA vous concernent.

    Limites et dépendances

    Déterminer si vous entrez dans le champ d’application, et comment s’applique la transposition nationale, reste du ressort de vos équipes conformité et juridique.

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

    Notre méthode

    Nous rendons les coûts visibles par produit et ajoutons des garde-fous : budgets, quotas et arrêt programmé des environnements inactifs.

    Limites et dépendances

    Les économies les plus importantes viennent généralement des décisions d’architecture et d’usage prises par les responsables produit, pas de la plateforme seule.

05 Notre façon de travailler

Notre façon de travailler

Les fondations d’abord, puis une équipe sur le chemin balisé, puis toutes les autres.

  1. 01

    Évaluer et classer

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

    LivrableClassification des charges de travail et options cibles

  2. 02

    Construire la zone d’atterrissage

    Tout en code, revu avec la sécurité, avec un processus de dérogation.

    LivrableZone d’atterrissage en production

  3. 03

    Intégrer une équipe pilote

    Une équipe produit adopte le chemin balisé ; ses points de friction façonnent la plateforme.

    LivrablePremier service sur la plateforme

  4. 04

    Étendre et assurer la passation

    D’autres équipes rejoignent la plateforme, l’équipe plateforme en prend la responsabilité, et la reprise est testée à intervalles réguliers.

    LivrableFeuille de route de la plateforme et rapports de tests de reprise

06 Contrôle humain

Là où l’humain garde la main

L’automatisation fait tourner la plateforme. Les décisions qui comportent un risque ou un coût appartiennent à des personnes.

  • Les changements en production sont traçables

    Chaque changement en production provient d’un commit revu : qui a modifié quoi et qui l’a approuvé est toujours enregistré.

  • Les accès d’urgence sont rares et journalisés

    Les accès d’urgence (break-glass) sont limités dans le temps, doivent être justifiés et sont revus a posteriori.

  • Les dérogations ont un responsable

    Lorsqu’une charge de travail a besoin d’une dérogation à un garde-fou, un responsable des risques désigné l’approuve, avec une date d’expiration.

  • Les responsables de service fixent les objectifs

    Les objectifs de reprise et les niveaux de service sont convenus avec le responsable métier de chaque service, pas fixés par la seule équipe plateforme.

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 managées
  • Plateformes serverless et de conteneurs
  • Service mesh lorsqu’il se justifie
  • Pools de nœuds GPU pour les charges de travail d’IA
Exploitation
  • OpenTelemetry
  • Prometheus et Grafana
  • Supervision native du cloud
  • Moteurs de règles tels qu’OPA

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

Deux socles, une seule exploitation

01Situation
Un groupe de protection sociale migre ses applications : la plupart vers un cloud public, celles qui traitent des données de santé ou sensibles vers un hébergement qualifié SecNumCloud et certifié HDS.
02Ce que nous construirions
Deux socles construits à partir du même code d’infrastructure, avec politiques de sécurité, journalisation et supervision communes, et un catalogue qui oriente chaque application selon sa classification.
03Là où l’humain décide
Le RSSI valide la classification de chaque application avant migration ; toute dérogation est tracée et revue chaque trimestre.
04Ce que nous mesurerions
Applications migrées par mois, écarts de configuration détectés, coût mensuel par environnement, durée de restauration testée.

09 Regard sectoriel

Dans votre secteur

  • Secteur public et administrations

    Des options de souveraineté par classe de données, des qualifications de sécurité nationales et des plans de réversibilité qui survivent au prochain marché public.

  • Services financiers

    La résilience opérationnelle au sens de DORA : reprise testée, surveillance des prestataires tiers de services TIC et notification des incidents intégrées à l’exploitation.

France

Doctrine « cloud au centre » et SecNumCloud

La doctrine « cloud au centre » fait du cloud l’hébergement par défaut des services de l’État et réserve les données d’une sensibilité particulière à des offres qualifiées SecNumCloud par l’ANSSI. De nombreuses grandes entreprises appliquent désormais une grille comparable, sous l’effet de NIS2.

Nous concevons des socles où classification des données, hébergement et journalisation sont des règles, pas des projets : chaque application rejoint l’environnement adapté à sa sensibilité. Les plans de réversibilité s’appuient sur le règlement européen sur les données et sont testés.

Questions sur l’ingénierie cloud et plateformes

Quel fournisseur cloud recommandez-vous ?

Celui qui correspond à vos charges de travail, à vos contrats existants et à vos exigences de souveraineté. Nous travaillons avec les principaux hyperscalers et les offres souveraines européennes, et nous documentons les compromis pour que le choix puisse être défendu lors de l’achat et réexaminé plus tard.

Avons-nous besoin de Kubernetes ?

Pas toujours. Kubernetes se justifie lorsque vous exploitez de nombreux services et disposez d’une équipe pour gérer la plateforme. Pour quelques services, des plateformes de conteneurs managées ou serverless sont souvent plus simples et moins coûteuses à exploiter.

Comment abordez-vous la sécurité ?

La sécurité est intégrée à la zone d’atterrissage et aux chaînes de livraison : identités au moindre privilège, policy as code, artefacts signés et secrets qui ne figurent jamais dans le code. FromNine est elle-même certifiée ISO/IEC 27001 pour son système de management de la sécurité de l’information.

Pouvez-vous réduire nos coûts cloud ?

En général, oui, mais nous ne promettons pas de pourcentage avant d’avoir vu les données. Nous commençons par rendre les coûts visibles par produit, puis nous traitons un backlog d’économies avec les responsables en mesure d’agir.

Comment éviter la dépendance à un fournisseur ?

En choisissant délibérément les points où vous acceptez de dépendre de services propres à un fournisseur, en gardant l’infrastructure en code et en maintenant un plan de sortie documenté et testé. Le Data Act renforce vos droits de changement de fournisseur ; un plan de réversibilité les rend exploitables.

Clarifions vos choix d’hébergement

Apportez votre cartographie applicative et la classification de vos données. Nous vous aidons à décider ce qui va où, et à quel coût, avant la première migration.

Échanger sur votre projetDécouvrir notre approche