Systèmes d'information & Cloud

Chaque nouveau besoin rouvre l'ensemble : trois semaines annoncées, deux mois réels, et un système un peu plus fragile à chaque fois. La question n'est pas la technologie — c'est ce qu'elle permet d'ajouter sans tout rouvrir.

Un système d'information se juge à ce qu'il permet d'ajouter demain sans tout rouvrir.

Système opérable

Des milliards de lignes sur un bureau — et en ligne quand il faut

Une base analytique ne demande pas un centre de données pour commencer. La scène range cinq mille quatre cents lignes en colonnes, les compresse, les pose sur la silhouette d'un portable, puis envoie une copie vers une baie et tient les deux à jour : deux copies, une seule vérité. Une forme et un mouvement — aucune donnée réelle dans la scène.

Systèmes d'information & cloud

La base qui tient sur un bureau

Cinq mille quatre cents lignes en vrac se rangent en colonnes, une par type ; ce qui se ressemble se compresse ; l'ensemble se pose sur la silhouette d'un portable. Puis une copie part vers une baie, et une impulsion tient les deux à jour : deux copies, une seule vérité.

Une entreprise qui croit qu'il faut un centre de données pour interroger des milliards de lignes — et qui aimerait commencer sur la machine qu'elle a déjà.

Regardez le vrac devenir des colonnes, puis partir en ligne.

Three.js · WebGL · 5 400 cubes instanciés · 4 types · compression · synchronisation · récit en 5 chapitres · repli sans WebGL

La plateforme de données, vue de l'infrastructure

Ce qui tient une plateforme debout quand elle grossit : les contrats, les couches, et ce qui refuse d'écrire quand le compte n'y est pas.

DEV & TECHNOLOGIE · DATA

Savoir d’où vient une donnée avant de décider avec elle.

Contrats, qualité, lineage et propriétaires rendent la plateforme explicable.

Une donnée rapide mais non traçable accélère surtout la mauvaise décision.

FIABLE · DÉGRADÉ · EN QUARANTAINE · N.F

Méthode

Contrats de données versionnés, événements de lineage et SLO de fraîcheur / qualité.

Contrat : schéma · sémantique · propriétaire · compatibilité
Lineage : dataset · job · run
Qualité : complétude · unicité · validité · fraîcheur
Changement cassant · période de dépréciation
Quarantaine et rejeu idempotent
Observabilité : traces · métriques · logs

Le lineage établit d'où vient une donnée et où elle va. La qualité et la licéité s'instruisent en plus, et nous les instruisons.

Des systèmes qui tiennent seuls, racontés sans les noms

Un site servi sur deux mondes, un entrepôt exploité chaque nuit sans intervention, un pont vers l'extérieur où rien de nominatif ne passe : ce que nous avons monté, ce que ça a produit, et ce qui était difficile. Noms retirés, volumes gardés.

RÉFÉRENCES · MISSIONS RÉELLES, NOMS CENSURÉS

01
Notre propre maison — un cabinet à trois métiers, deux publics qui ne cherchent pas la même chose, et deux langues.
Quand · Été 2026, en production et remanié chaque semaine.
Ce que nous avons fait
Nous avons conçu et bâti ce site de bout en bout : l'architecture, le dessin, le texte, les scènes en trois dimensions, et le miroir anglais. L'anglais n'est pas un bouton qui repeint la page — c'est un jeu d'adresses à lui, sans quoi aucun moteur ne le voit.
Ce que ça a produit
Un site à deux mondes, entièrement bilingue, dont chaque page anglaise a sa propre adresse et sa relation réciproque avec la française. Sept contrôles automatiques tiennent la publication, enchaînés par une seule commande : régimes de fond, feuilles de style, charte, teintes de texte, données structurées, adresses par langue, matière des sous-pages. Le premier défaut arrête la chaîne — c'est un refus, pas un avertissement.
Ce qui était difficile
L'anglais existait déjà, mais dans un état d'affichage : aucune adresse ne le rendait. Deux états d'un même document ne sont pas deux documents — la balise qui relie les langues relie des adresses, et elle n'avait rien à relier. Il a fallu séparer les URL avant d'espérer être lu ailleurs qu'en France.
02
Notre propre maison, puis le modèle repris pour des organisations dont les données vivent dans des outils qui ne se parlent pas.
Quand · Bâti en 2026, exploité tous les soirs depuis.
Ce que nous avons fait
Nous avons bâti un entrepôt analytique et l'ordonnanceur qui le remplit. Il part seul chaque soir, étape par étape. Machine éteinte, il part au démarrage suivant ; réseau absent, il attend ; une étape tombée n'arrête pas les autres et repart le lendemain. Chaque étape écrit son verdict, daté, et le bilan du soir distingue trois états : échec, report, et réussite après une machine occupée.
Ce que ça a produit
Un ordonnanceur quotidien dont le nombre d'étapes se lit dans le code et jamais dans un document, un journal daté par étape, et un état du jour régénéré à chemin fixe — chercher le bon fichier serait déjà une intervention humaine.
Ce qui était difficile
Des milliards de lignes tenues sur une machine de bureau, avec seize gigaoctets de mémoire. Ce n'est pas une prouesse d'affichage : c'est ce qui décide de l'architecture — traitement source par source, formats colonnaires, et un verrou d'écriture unique, parce qu'un seul lecteur resté ouvert suffit à bloquer toute la nuit.
03
Une structure qui doit ouvrir une partie de son analyse à l'extérieur sans que rien de nominatif ne franchisse le mur.
Quand · Septembre 2026, en service.
Ce que nous avons fait
Nous avons relié une interface publique à un service d'analyse interne : écoute fermée sur la boucle locale, débit borné par appelant, secret de machine lu côté serveur — jamais tapé sur une ligne de commande, où il resterait dans l'historique et dans la table des processus — et une purge du nominatif exécutée avant tout affichage.
Ce que ça a produit
Une épreuve du pont qui rejoue les quatre décisions (adresse acceptée, débit, mode servi, texte libre) et un banc qui injecte des noms fabriqués dans la chaîne pour vérifier qu'ils en ressortent purgés. Les deux tournent sans qu'aucun serveur soit allumé, donc ils tournent vraiment.
Ce qui était difficile
« Interne » se lisait dans un en-tête que tout client non-navigateur choisit librement : depuis le réseau local, un appel pouvait se déclarer interne et obtenir le mode complet. On ne vérifie pas mieux qui frappe à la porte — on ferme la porte qui donne sur la rue.

Aucun nom de client n'est publié, avec ou sans son accord. Nous ne publions pas de taux de réussite : il n'est pas mesuré, et un chiffre non mesuré n'est pas une référence.

Ce que nous faisons

Architecture et schéma directeur : ce qui vit où, et pourquoi.
Cloud, hébergement, environnements, sauvegardes et restauration testée.
Intégrations et APIs entre outils existants : ERP, CRM, applications métier.
Migrations : reprise de données, bascule par lots, retour arrière prévu.
Industrialisation du déploiement et supervision de l'exploitation.
Séparation de ce qui se lit et de ce qui s'écrit : il suffit d'un seul processus tenant le verrou pour bloquer une reconstruction nocturne, et l'écriture doit réessayer au lieu d'abandonner.
Mesure de ce qui pèse et de ce qui s'accumule chaque mois, avec la décision qui l'arrête. Une taille logique n'est pas une occupation disque, et un index se reconstruit : le compter dans un volume de données, c'est compter la table des matières dans le nombre de pages.
Reprise après incident réellement jouée : une restauration qu'on n'a jamais exécutée n'est pas une restauration, c'est une intention.

Ce que nous livrons

Schéma d'architecture & schéma directeur SI

Environnements & chaîne de déploiement

APIs & connecteurs documentés

Plan de migration & procédure de bascule

Plan de sauvegarde & compte rendu de restauration réellement exécutée

Journal daté des mesures d'occupation, avec l'écart calculé d'une mesure à l'autre

Supervision, alertes & procédures d'exploitation

Procédure de réparation imprimée par l'outil qui annonce la panne

La méthode

Cartographier

L'existant réel, y compris ce qui n'est écrit nulle part — et surtout ce qui tourne tout seul la nuit sans que personne ne s'en souvienne.

Dessiner

Une cible sobre : la complexité ne s'achète que si elle rapporte.

Basculer

Par lots, avec un retour arrière possible à chaque étape. On mesure l'espace d'abord et on bâtit à côté : détruire avant de savoir si l'on peut reconstruire n'est pas une reconstruction, c'est une destruction suivie d'un espoir.

Exploiter

Mesure, alertes, mises à jour : un système vit, il n'est jamais « fini ». Et la mesure de la veille est conservée, sinon rien ne peut signaler une dérive.

CE QUE VOUS AUREZ EN MAIN · La carte des flux et des dépendances

Ajoutez une capacité : la carte révèle les contrats réutilisés, les frontières franchies et le point qui doit évoluer.

Ce qui dépend de quoi, en cascade.

Nous concevons un socle qui rend les prochains changements moins coûteux à comprendre, tester et livrer. L’architecture visible relie les capacités du métier, les données qu’elles emploient, les systèmes qui les exécutent et les frontières de responsabilité.

Le dirigeant voit les dépendances critiques, les points uniques de rupture et ce qui peut être remplacé sans toucher au reste. Les choix cloud, sur site, souverains ou air-gapped sont présentés comme des frontières d’usage et d’exploitation, pas comme des étiquettes.

Explorer l’architecture

Capacité → contrat → service → donnée → contrôle

Le spécialiste ouvre les contrats d’API, événements, propriétaires, objectifs de service, flux de données et modes de reprise. La carte distingue la dépendance logique de l’implémentation physique afin qu’une migration reste un changement explicite.

Le mode scénario coupe une dépendance, ferme une zone réseau ou épingle une release. Il montre le service qui continue, le repli attendu, la preuve à observer et l’action de reprise. Une dépendance sans propriétaire reste N.F. et bloque la promotion.

Cartographie de capacités, applications, données, interfaces, propriétaires, obsolescence et dette.

C4, frontières de confiance, ADR, principes d’architecture et matrice de responsabilités.

Placement de workload selon latence, criticité, résidence, connectivité, compétences, réversibilité et coût unitaire.

Control plane, data plane et management plane séparés, avec flux entrants et sortants explicitement autorisés.

Zero Trust : identité humaine et de service, authentification et autorisation par ressource, sans confiance implicite liée au réseau.

API, événement, CDC, file, retry borné, identifiant d’événement stable, consommateur idempotent et circuit breaker.

Infrastructure as Code, artefact immuable et signé, dérive de configuration, promotion et attestation.

SLO, budget d’erreur, métriques, logs, traces, profils, alertes et runbooks.

RTO, RPO, sauvegarde immuable/hors ligne, restauration, bascule et test de reprise.

Progressive delivery, canary, blue/green, feature flag, stratégie de rollback et migration expand/contract.

SBOM, VEX, provenance, dépôt miroir, mise à jour hors ligne, PKI/KMS/HSM et gestion du cycle de vie des secrets.

FinOps et réversibilité : allocation, coût par unité de service, engagement, egress, portabilité des données et plan de sortie testé.

D'où ça vient

ILLUSTRATIF3 sites dont 1 zone air-gapped, pour un produit dépendant de 27 interfaces recensées de façon incomplète.provisoire
ILLUSTRATIF4 dépendances d’exécution externes incompatibles avec le profil air-gapped : identité, registre d’artefacts, télémétrie, validation de licence.provisoire
ILLUSTRATIFLot hors ligne de 14 artefacts ; 1 artefact non approuvé provoque le rejet complet du lot.provisoire
ILLUSTRATIFTest de restauration au-delà du RTO cible de 4 h, avec un dépassement de 38 min : statut ÉCART OUVERT.provisoire

La carte éclaire l’architecture et ses dépendances ; elle ne revendique aucun statut externe et ne remplace ni la vérification physique et logique d’un profil air-gapped, ni une qualification ou une homologation, qui relèvent d’un périmètre et d’une preuve distincts.

LES QUESTIONS QUI FONT LE PRIX

Ce que nous vous demanderons avant de commencer.

Quatre questions que nous posons à chaque dossier de ce domaine. Chacune vient d'un incident payé — par nous, ou par un maître d'ouvrage avant nous.

Un seul lecteur peut-il bloquer toute la nuit ?

Oui : il suffit d'un seul processus qui tient le verrou pour empêcher une reconstruction. Nous séparons ce qui se lit de ce qui s'écrit, nous publions des référentiels figés et nous faisons réessayer l'écriture.

Si personne ne la pose — Une mise à jour nocturne qui échoue en silence à cause d'un onglet resté ouvert.

Détruit-on avant de savoir si l'on peut reconstruire ?

Jamais. Toute reconstruction mesure l'espace d'abord et bâtit à côté ; l'existant n'est touché qu'une fois le remplaçant prouvé. Détruire avant de savoir n'est pas une reconstruction : c'est une destruction suivie d'un espoir.

Si personne ne la pose — Un index détruit à une heure du matin, et une reconstruction impossible faute de vingt-cinq gigaoctets.

Que coûte réellement l'infrastructure, et qu'est-ce qui la fait grossir ?

Nous mesurons ce qui pèse — bases, fichiers, index — et ce qui s'accumule chaque mois, avec la décision qui l'arrête. Une taille logique n'est pas une occupation disque, et un index se reconstruit : il ne se compte pas dans les données.

Si personne ne la pose — Un disque plein en dix jours, et personne ne sait ce qui l'a rempli.

Que se passe-t-il quand le système tombe, pour celui qui arrive trois semaines plus tard ?

Le quoi-faire-quand-ça-casse s'imprime depuis l'outil qui annonce la panne, avec la commande à lancer. On grave toujours le pourquoi ; on oublie toujours la réparation — c'est pourtant la seule chose dont a besoin celui qui trouve un voyant rouge.

Si personne ne la pose — Une panne à huit heures du matin et un mode d'emploi introuvable.

SCÉNARIO DE CAPACITÉ — PAS UNE RÉFÉRENCE CLIENT

Quand on nous appelle

Une société accumule des outils qui ne se parlent pas et fait ressaisir les mêmes données trois fois. Nous cartographions les flux, ouvrons les intégrations qui suppriment la ressaisie et rangeons le reste derrière une architecture explicite. La bascule se fait par lots, avec un retour arrière à chaque étape.

Domaines croisés

Un dossier mobilise rarement un seul domaine.

Cybersécurité & Audit

Exposition maîtrisée

Développement & Design produit

Produit opérable

Tous les domaines du pôle

Un projet Systèmes d'information & Cloud ?

Écrivez-nous. Nous répondons avec une lecture, pas une plaquette.

Nous écrire