Audit d’infrastructure data, due diligence technique et dimensionnement

Ce qui déclenche une revue

Avant un engagement

• Vous investissez dans une société, vous l’acquérez ou vous entrez à son capital, et sa valeur dépend d’une plateforme technique.
• Vous êtes sur le point de vous engager sur un produit data, IA ou infrastructure stratégique et vous voulez confronter les promesses aux preuves.
• Vous devez dimensionner une nouvelle plateforme et choisir serveurs, instances ou stockage avant de signer le budget.
• Une migration, un re-plateforming ou une refonte d’architecture démarre, et les hypothèses n’ont jamais été challengées de l’extérieur.
• Un fournisseur a proposé une configuration et personne en interne ne peut vérifier si elle est juste, généreuse ou sous-dimensionnée.

Sous contrainte de charge

• Le trafic, le volume de données ou la demande d’entraînement de modèles va augmenter d’un facteur important et vous devez savoir ce qui cède en premier.
• Les coûts d’infrastructure augmentent plus vite que l’usage et les causes sont réparties entre plusieurs équipes.
• Votre plan de reprise d’activité n’a jamais été testé en conditions réalistes, et les RTO / RPO annoncés doivent survivre à une bascule réelle.

Quand la plateforme devient la contrainte

• Vos jobs Spark sont lents, instables ou coûteux.
• Vos pipelines Kafka sont difficiles à opérer à grande échelle.
• Ceph, MinIO, Cassandra ou la couche de stockage produisent une latence ou une fiabilité imprévisibles.
• La plateforme data freine vos initiatives IA ou analytics.

Ma méthode : toutes les couches, une seule revue

Je ne limite pas une revue à un seul produit, une seule couche logicielle ou une seule équipe. Selon la question posée, l’investigation traverse :

• le code source applicatif, les algorithmes et les modèles de données ;
• les moteurs de traitement distribué, les bases de données et les systèmes de messagerie ;
• Kubernetes, l’orchestration de conteneurs et l’ordonnancement ;
• le réseau et les chemins de données ;
• le stockage objet, bloc et distribué ;
• la configuration du système d’exploitation et de l’infrastructure ;
• l’architecture des serveurs, les spécifications des disques et leur comportement mesuré ;
• le plan de capacité et la proposition fournisseur qui accompagne l’achat.

Je peux passer, dans une même mission, de la lecture du code source d’un job Spark à la remise en cause des spécifications de disques dans un devis fournisseur. Cette amplitude est le cœur de la valeur. Les revues qui s’arrêtent à la frontière d’une couche produisent des diagnostics incomplets, des optimisations qui déplacent le goulot d’étranglement ailleurs, du surdimensionnement acheté comme une assurance, des refontes qui n’étaient pas nécessaires, un dimensionnement dicté par celui qui vend le matériel, et des mois d’essais et d’erreurs pendant que cinq équipes défendent cinq hypothèses plausibles.

Mes offres

Audit data platform : à partir de 7 500 € HT

Fourchette typique : 7 500 € à 15 000 € HT selon le périmètre, l’urgence et la complexité du système.

Une revue complète d’une plateforme data, cloud ou IA complexe dont la performance, la scalabilité, la fiabilité ou le coût ont un impact business. C’est la mission adaptée aux problèmes transverses, aux plateformes qui vont franchir un palier de charge important, et aux décisions qui demandent plus d’éléments qu’une revue de composant isolé.

Livrables types : cartographie d’architecture ; analyse des goulots d’étranglement ; risques de fiabilité et de scalabilité ; modèle de coûts et de capacité ; quick wins ; roadmap priorisée ; restitution exécutive pour CTO, VP Engineering ou Head of Platform.

Due diligence technique : à partir de 4 500 € HT

Une lecture technique indépendante pour investisseurs, acquéreurs et comités de direction, avant d’investir dans une société, d’acquérir des parts, de valider une plateforme fournisseur ou de s’engager sur un produit d’infrastructure data ou IA stratégique.

Périmètre type : revue d’architecture et de code source quand il est accessible ; évaluation des risques de scalabilité, de fiabilité et d’infrastructure ; dette technique et maturité opérationnelle ; trajectoire de coûts induite par l’architecture actuelle à l’échelle visée ; confrontation des affirmations du fournisseur ou de la cible aux preuves disponibles ; note de risque écrite avec les éléments de décision et les questions de suivi priorisées.

Idéal pour : les investisseurs qui ont besoin d’une diligence technique avant une opération, les dirigeants qui évaluent une acquisition dont la valeur repose sur une plateforme, et les équipes qui s’engagent sur un produit où la performance, la dépendance fournisseur, la fiabilité ou le coût changeraient sensiblement le business case.

Dimensionnement et plan de capacité : à partir de 4 500 € HT

Un dimensionnement fondé sur des mesures, pour un nouveau déploiement, une montée en charge, une migration ou une décision de re-plateforming.

C’est l’un de mes domaines les plus solides. Je dimensionne les composants open source (Kafka, Cassandra, ScyllaDB, Ceph, MinIO, PostgreSQL, Kubernetes, Spark, Pulsar) face à la charge réelle, puis je traduis le résultat en matériel concret : les bons types d’instances dans un catalogue cloud public, ou la bonne configuration de serveurs et de disques dans un catalogue constructeur type Dell ou HPE. Quand un fournisseur a déjà proposé une configuration, je la confronte à ce dont les composants ont réellement besoin et à ce que le matériel délivre réellement.

Périmètre type : analyse de la charge cible ; dimensionnement compute, stockage et réseau ; sélection de serveurs et d’instances dans les catalogues cloud ou constructeurs ; recommandations de marge de capacité ; estimation de coût selon l’infrastructure retenue, on-premise, cloud privé ou cloud public ; document de dimensionnement écrit et restitution.

Revue d’architecture flash : à partir de 4 500 € HT

Une décision critique, un goulot d’étranglement ou un composant système, examiné en profondeur et tranché rapidement.

Périmètre type : revue d’architecture ; entretiens techniques ; revue de métriques, logs et configurations quand elles sont disponibles ; diagnostic écrit ; recommandations priorisées ; restitution avec le CTO, le tech lead ou l’équipe plateforme.

Évaluation résilience et plan de reprise : à partir de 4 500 € HT

Une validation technique de la capacité réelle de votre plateforme à survivre aux pannes qu’elle est censée absorber, et à redémarrer dans la fenêtre promise au métier.

Périmètre type : analyse des scénarios de panne et de leur périmètre d’impact ; revue de la conception haute disponibilité et tolérance aux pannes ; topologie de réplication, cohérence et retard de réplication en cas de partition ; intégrité des sauvegardes et débit de restauration mesuré face aux volumes réels ; ordre des dépendances pendant la reprise ; pratique des tests de restauration ; verdict d’atteignabilité sur les RTO et RPO annoncés, avec l’analyse d’écart correspondante.

Avant implémentation, cela permet d’identifier les choix de conception qui rendent la cible inatteignable. Après implémentation, cela vérifie que le document décrit bien le système qui tourne. Les plans de reprise échouent sur des détails qui n’apparaissent qu’au test : une réplication silencieusement en retard, un chemin de restauration limité par le débit, une procédure qui suppose disponible un plan de contrôle lui-même touché par la panne.

Revue d’optimisation des coûts : à partir de 4 500 € HT

Une revue technique de ce que coûte votre plateforme et pourquoi, reliée aux choix d’ingénierie qui produisent la facture.

Dans une plateforme data, le coût n’appartient presque jamais à une seule équipe. Le dimensionnement des exécuteurs, les quotas Kubernetes, l’organisation du stockage et le facteur de réplication, la politique de rétention, l’allocation GPU, la capacité inutilisée, les transferts de données et la tarification fournisseur y contribuent tous. Je passe en revue chaque poste avec les preuves techniques correspondantes, pour que vous puissiez distinguer le gaspillage de la marge que vous avez raison de conserver.

Périmètre type : répartition des coûts par charge de travail ; opportunités de redimensionnement avec les mesures qui les justifient ; économie du stockage, de la réplication et de la rétention ; analyse de l’ordonnancement et du taux d’utilisation ; revue des engagements et de la tarification fournisseur ; liste de réductions classées avec effort et risque associés.

Appel expert : 250 € HT / 1h

Une session vidéo focalisée sur une question d’architecture, de performance, de scalabilité, de résilience ou de coût. Idéal pour valider une orientation, challenger une proposition ou obtenir un avis externe avant une décision plus large. C’est un produit autonome, pas une étape à acheter avant un audit.

Senior Advisor récurrent : à partir de 3 000 € HT / mois

Une revue senior récurrente pour les équipes qui opèrent une infrastructure data complexe. Quelques heures par mois de challenge d’architecture indépendant, d’analyse d’incidents et d’appui sur la roadmap, sans recruter un principal engineer à temps plein. L’appel de découverte pour cette offre est gratuit.

Pour qui c’est fait, pour qui ce n’est pas fait

C’est pour : investisseurs, acquéreurs, CTO, DSI, responsables plateforme et data, VP Engineering et responsables SRE qui évaluent, dimensionnent, font monter en charge ou opèrent une infrastructure data, cloud ou IA en production, quand la performance, la fiabilité, la résilience, la dette technique ou le coût ont un impact business mesurable.

Ce n’est pas pour : le renfort de capacité (staff augmentation), le freelance individuel longue durée, la stratégie cloud générique, ou les missions d’un périmètre inférieur à 5 000 €. Si la question tient en une heure, l’Appel expert est le bon point d’entrée et je vous le dirai dès l’appel de cadrage.

Les systèmes que j’audite

La revue se concentre sur les systèmes qui décident le plus souvent de la performance, de la capacité et du coût dans les plateformes data matures.

Spark sur Kubernetes

J’examine le dimensionnement des executors, l’overcommit CPU, le comportement du shuffle, les hypothèses d’autoscaling, les files d’attente, les limites de namespace, les échecs de pods, les schémas d’accès au stockage objet et les timelines de jobs. L’objectif est de séparer ce qui relève du tuning Spark de ce qui relève de l’ordonnancement Kubernetes, du stockage ou du réseau.

Stockage objet, Ceph et MinIO

Je regarde la latence, le débit, le taux d’opérations S3, l’erasure coding, l’agencement des disques, les chemins réseau, la pression sur les métadonnées, le comportement sur les petits fichiers, les règles de cycle de vie et les domaines de panne. Un stockage objet peut paraître sain au niveau du bucket pendant que Spark, l’entraînement de modèles ou les charges analytics subissent une amplification des requêtes et une tail latency instable.

Cassandra et ScyllaDB

J’examine les modèles de données, la taille des partitions, la compaction, les tombstones, le comportement JVM et GC, les pratiques de repair, l’équilibre entre nœuds, les percentiles de latence et l’historique des incidents. Sur une base opérationnelle, le débit maximal compte moins que la prévisibilité. La vraie question est de savoir si la plateforme tient une latence prévisible sous la charge réelle de production.

Kafka, cloud privé et infrastructure IA

J’examine le dimensionnement des brokers, la rétention, le consumer lag, la topologie réseau, la contention sur le stockage, le taux d’utilisation des GPU, l’ordonnancement des batchs et l’allocation de capacité. En cloud privé, un même goulot d’étranglement physique peut affecter Spark, Kafka, le stockage objet et les charges IA en même temps.

Les signaux que j’examine

Une revue utile part de preuves. Je travaille en général sur les timelines de jobs, les dashboards Prometheus et Grafana, les profils CPU et mémoire, les métriques JVM, la latence et le débit S3, les schémas d’I/O, les chemins réseau, l’historique des redémarrages de pods, les événements de l’ordonnanceur, les files d’attente, les statistiques de compaction Cassandra, les pauses GC, les postmortems d’incidents, les plans de capacité, les devis fournisseurs et la répartition des coûts cloud ou cloud privé.

J’examine aussi les hypothèses de vos équipes. Beaucoup d’équipes plateforme connaissent déjà une partie de la réponse, mais il leur manque le temps, le recul externe ou les preuves transverses. La revue transforme ces signaux en un diagnostic clair et en une liste de décisions priorisées.

Livrables

• Cartographie d’architecture : les systèmes, les dépendances, les chemins de données et les frontières de responsabilité qui comptent pour la performance et la fiabilité.
• Analyse des goulots d’étranglement : les contraintes qui expliquent les jobs lents, la latence instable, la hausse des coûts ou les incidents de fiabilité.
• Registre de risques : les points de fiabilité, de scalabilité, de résilience, d’opérabilité et de dépendance fournisseur que la direction doit suivre.
• Modèle de dimensionnement et de coûts : les hypothèses de compute, de stockage, de réseau et de capacité, avec l’impact sur le coût quand les données le permettent.
• Roadmap 30 / 60 / 90 jours : correctifs priorisés, quick wins, décisions à reporter et changements qui demandent un vrai travail d’ingénierie.
• Synthèse exécutive : une version lisible pour un CTO, un VP Engineering, un Head of Platform, un investisseur ou un acquéreur.

Ce que ce n’est pas

Ce n’est ni du renfort de capacité, ni un projet de migration cloud générique, ni de l’implémentation fournisseur, ni un programme de transformation digitale, ni une mission freelance longue durée. Le travail est diagnostique et orienté décision. Il vous aide à trancher ce qu’il faut construire, ce qu’il faut acheter, ce qu’il faut corriger, et où le temps d’ingénierie rapporte le plus.

Ce dont j’ai besoin de votre côté

Les meilleurs éléments d’entrée sont les schémas d’architecture, les dashboards de métriques, les extraits de configuration, les rapports d’incidents, des échantillons de charge, les rapports de coûts, les plans de capacité, les propositions fournisseurs et des entretiens avec les ingénieurs qui opèrent la plateforme. Un accès production est rarement nécessaire. De bonnes preuves et des échanges techniques directs suffisent en général à identifier les contraintes principales.

Sélection de missions clients

Liste non exhaustive d’engagements passés. Je nomme certains clients avec leur accord ; j’anonymise les autres.

• BPCE-IT : Performance et fiabilité Cassandra pour une plateforme d’API Management. « Son expertise et ses compétences ont contribué à améliorer la performance et le comportement de nos plateformes. »
• Data lake privé multi-pétaoctets : audit indépendant d’un grand data lake on-premise supportant des charges analytics et IA
• MinIO et Ceph à grande échelle : performance et observabilité sur stockage objet en production
• Spark sur Kubernetes : performance et fiabilité sur plateformes Spark en cloud privé
• Pipelines géospatiaux / imagerie satellite : design d’infrastructure pour traitement d’images haut volume

Références disponibles sur demande sous NDA.

Pourquoi moi

J’ai un PhD en optimisation numérique et calcul haute performance, et plus de 20 ans d’expérience hands-on en production sur des systèmes distribués, des plateformes data et du cloud privé.

J’ai travaillé sur des data lakes multi-pétaoctets, Spark sur Kubernetes, du stockage objet Ceph et MinIO, Cassandra et ScyllaDB, des pipelines d’imagerie satellite, de l’infrastructure bancaire, des plateformes télécom et des systèmes aérospatiaux.

Je ne vends ni implémentation, ni licences, ni matériel, et je travaille seul. Vous obtenez un avis senior unique, assumé et sans détour, dont aucune conclusion ne dépend de ce que vous achèterez ensuite.

Résultats types

Selon le contexte, mes clients utilisent la revue pour :

• Dimensionner une plateforme face à la charge qu’elle portera réellement
• Réduire les temps de traitement
• Baisser le coût d’infrastructure
• Identifier les goulots d’étranglement stockage ou compute
• Vérifier que les objectifs de reprise sont atteignables
• Sécuriser une migration ou une montée en charge
• Améliorer la fiabilité en production
• Challenger les recommandations d’un fournisseur, d’un intégrateur ou d’une société cible
• Faire remonter les risques techniques avant un investissement, une acquisition ou un engagement stratégique
• Prioriser le travail d’ingénierie
• Éviter le surdimensionnement et les dépenses cloud inutiles

Scénarios d’intervention fréquents

On ne m’appelle presque jamais parce qu’un dashboard est au rouge. On m’appelle quand plusieurs systèmes interagissent mal, quand une décision approche et que les éléments manquent, ou quand le diagnostic interne ne fait plus consensus. Voici les situations que je rencontre le plus souvent.

Une plateforme doit absorber une forte montée en charge

Le volume de données, le trafic ou la demande d’entraînement va croître d’un facteur que personne n’a testé. La question n’est pas de savoir si la plateforme tient aujourd’hui. Elle est de savoir quel composant sature en premier, à quel seuil, et si la réponse relève de la configuration, de l’agencement des données, de la capacité ou de l’architecture.

Je modélise la croissance face à la charge réelle, j’identifie les trois premières contraintes dans l’ordre, et je vous donne le dimensionnement et la séquence : ce qu’il faut changer avant l’arrivée de la charge, ce qu’il faut acheter, et ce qui tiendra plus longtemps que l’équipe ne le pense.

Une proposition fournisseur doit être vérifiée de façon indépendante

Vous avez un devis pour des serveurs, du stockage ou une plateforme managée, et personne en interne ne peut le vérifier. Le dimensionnement fournisseur est rarement faux volontairement. Il repose sur des hypothèses génériques, il est calibré sur le risque du fournisseur plutôt que sur le vôtre, et il est chiffré à partir de spécifications qui décrivent le matériel dans des conditions que votre charge ne reproduira pas.

Je confronte la configuration à ce dont les composants ont réellement besoin et à ce que l’équipement délivre réellement sous votre schéma d’accès : caractéristiques des disques, limites des contrôleurs et du réseau, surcoût de l’erasure coding, facteur de réplication, marge de capacité. Vous en ressortez avec une position défendable en négociation.

Les jobs Spark sont lents, instables ou coûteux

Un problème Spark peut venir du code, du partitionnement, du shuffle, de l’agencement des fichiers, des limites Kubernetes, du stockage objet, de l’autoscaling, des files d’attente, ou d’un mélange de tout cela. J’examine ensemble les timelines de jobs, les métriques de stages, le comportement des executors, l’ordonnancement des pods, la latence du stockage et l’agencement des données. Cela évite de tuner une couche pendant que la vraie contrainte se trouve ailleurs.

Le résultat n’est pas une liste générique de bonnes pratiques Spark. C’est un diagnostic classé : quels jobs génèrent le coût, quels goulots d’étranglement sont structurels, quelles corrections sont rapides, et quels changements demandent du travail d’ingénierie ou des décisions de plateforme.

Le stockage objet fonctionne, mais les charges analytics en souffrent

Ceph, MinIO et les plateformes compatibles S3 peuvent paraître saines sur le dashboard de stockage pendant que les charges data subissent des performances instables. Les petits fichiers, l’amplification des requêtes, l’erasure coding, la contention disque, les chemins réseau et la pression sur les métadonnées créent tous un écart entre la santé brute du stockage et la performance applicative.

Je relie les métriques de stockage au comportement des charges : taux d’opérations S3, tail latency, distribution de la taille des objets, schémas de retry, débit par client, placement réseau et domaines de panne. L’objectif est de déterminer si la plateforme demande un changement d’agencement, un changement de capacité, un changement d’exploitation, ou un changement côté application.

La latence Cassandra ou ScyllaDB devient imprévisible

Les incidents de latence sur ce type de base viennent souvent d’une combinaison : dérive du modèle de données, tombstones, compaction, repairs, déséquilibre entre nœuds, pression JVM, comportement disque et schémas d’accès côté client. La latence moyenne ne raconte presque rien. Les signaux utiles sont les percentiles, la distribution, les partitions chaudes, le retard de compaction, l’amplification en lecture et la chronologie des incidents.

La revue sépare l’hygiène opérationnelle du risque architectural. Certains problèmes se règlent par la configuration ou par le processus de repair. D’autres révèlent un modèle de données qui ne correspond plus au trafic de production. La direction doit savoir dans quel cas elle se trouve avant d’engager des mois de travail.

Un plan de reprise n’a jamais été testé

Le document existe, les objectifs sont écrits, et le schéma d’architecture montre une réplication vers un second site. Personne n’a mesuré une restauration complète, basculé sous charge, ni vérifié si la séquence de reprise dépend d’un système qui serait lui aussi hors service.

Je passe en revue les scénarios de panne, le comportement de la réplication, le débit de restauration face aux volumes réels et l’ordre des dépendances, puis je rends un verdict direct sur l’atteignabilité des RTO et RPO annoncés, avec ce qu’il en coûterait de fermer l’écart.

Les coûts d’infrastructure augmentent sans propriétaire clair

Dans une plateforme data, le coût appartient rarement à une seule équipe. Le dimensionnement Spark, les quotas Kubernetes, l’agencement du stockage, la réplication, la rétention, l’allocation GPU, la capacité inutilisée et la tarification fournisseur y contribuent tous. Je passe en revue chaque poste avec la preuve technique correspondante, pour que l’équipe distingue le gaspillage de la marge nécessaire.

Le résultat est un modèle de coûts relié aux choix d’ingénierie. Il peut révéler une opportunité immédiate de redimensionnement, un problème d’agencement du stockage, un problème d’ordonnancement des charges, ou une décision de plateforme qui remonte au niveau exécutif.

Une décision stratégique demande une due diligence technique indépendante

Les investisseurs, les acquéreurs et les comités de direction ont souvent besoin d’une lecture technique rapide avant un engagement de plateforme, une acquisition, une sélection de fournisseur ou une décision de roadmap majeure. Je me concentre sur les éléments qui changent la décision : les promesses de scalabilité, la maturité opérationnelle, le risque plateforme caché, le risque de dépendance, l’exposition au coût et la crédibilité des correctifs annoncés.

Le livrable est écrit pour des décideurs, mais il repose sur une revue technique. Il donne une vue claire de ce qui est sain, de ce qui est risqué, de ce qui demande un suivi, et des affirmations à challenger avant d’engager de l’argent ou du temps de roadmap.

Comment je distingue les symptômes des causes

Je commence par cartographier le chemin de données, pas par supposer que le problème se trouve dans le composant qui alerte le plus fort. Un job Spark lent peut révéler une latence de stockage objet. Un incident de stockage objet peut venir du placement réseau. Un pic de latence Cassandra peut venir d’une pression de compaction créée par une évolution produit. Un problème de coût GPU peut venir de l’ordonnancement des pipelines, pas des GPU.

Je cherche des preuves transverses : des horodatages qui concordent, des changements de charge, des limites de capacité, des retries, des files d’attente, de la tail latency, de la saturation, des interférences entre charges colocalisées et des événements d’exploitation. C’est ce qui rend la revue utile même quand vos équipes comptent déjà d’excellents ingénieurs. La valeur ajoutée est la synthèse indépendante entre les couches.

Les recommandations finales sont classées par impact business, par effort d’implémentation et par risque. Certaines corrections sont immédiates. D’autres demandent une décision de conception. D’autres doivent être écartées parce qu’elles ajoutent de la complexité sans retour suffisant. Une bonne revue vous fait passer moins de temps à débattre des symptômes et plus de temps à prendre les bonnes décisions techniques.

Les décisions que cela permet de prendre

La mission est construite pour appuyer des décisions concrètes, pas pour produire un long rapport que personne n’assume. Les décisions typiques : comment dimensionner la prochaine plateforme, accepter ou non une configuration fournisseur, redimensionner ou non les charges Spark, modifier ou non l’agencement du stockage objet, ajuster ou non les quotas Kubernetes, reporter ou non une migration, financer ou non un chantier de résilience avant d’ajouter du périmètre produit, et comment découper une roadmap plateforme.

Pour les investisseurs et les acquéreurs, le livrable met en avant les risques techniques qui peuvent peser sur la valorisation, le coût d’intégration, les délais de livraison ou la marge opérationnelle. Pour les CTO et les responsables plateforme, il clarifie où le temps d’ingénierie doit aller en premier, et quelles pistes coûtent plus qu’elles ne rapportent.

Comment la mission est cadrée

Un bon cadrage est assez étroit pour produire une réponse nette, et assez large pour éviter l’optimisation locale. Je pars en général de la question business : une plateforme qui va monter en charge, une décision de dimensionnement, une proposition fournisseur, un objectif de reprise, une chaîne de reporting lente, une charge IA instable, une plateforme Spark coûteuse, une couche de stockage au comportement imprévisible, ou une due diligence technique avant une opération.

À partir de là, je définis les systèmes dans le périmètre, les preuves disponibles, les personnes à interviewer, l’échéance de décision et le résultat attendu. Si la réponse utile tient dans un Appel expert ou une Revue d’architecture flash, je vous le dis. Si la question est transverse, l’audit complet donne le temps de relier le comportement des charges, les métriques d’infrastructure, l’historique d’exploitation et l’impact sur les coûts.

Cela garde la mission efficace. Le but n’est pas d’inspecter tous les dashboards. Le but est de trouver les preuves qui changent la décision.

Comment ça se passe

1. Cadrage : Clarifier la question, les frontières du système, l’échéance et l’impact business attendu.
2. Investigation : Revue de l’architecture, du code, des métriques, des configurations, des plans de capacité, des incidents, des hypothèses de l’équipe et des contraintes.
3. Priorisation : Classer les contraintes, les risques, les quick wins et les corrections à fort retour.
4. Restitution : Diagnostic écrit et roadmap technique priorisée, puis présentation à votre équipe.

Notes techniques associées

Ces notes montrent le type de problèmes de production qu’une revue fait remonter et priorise. Elles sont publiées en anglais.

• Spark sur Kubernetes : overcommit CPU et patterns d’operator
• MinIO et les gros volumes de petits fichiers (LOSF)
• Réplication de site MinIO : le mode synchrone ne sauvera pas votre RPO
• Coût des infrastructures GPU et surdimensionnement
• Lakehouse à l’échelle : quand c’est le modèle opérationnel qui casse

FAQ

Avez-vous besoin d’un accès production ?

Généralement non. Les métriques, schémas d’architecture, extraits de configuration et entretiens techniques suffisent souvent à démarrer.

Cela peut-il se faire à distance ?

Oui. La plupart des missions sont remote-first.

Travaillez-vous avec des clients hors de France ?

Oui. Les missions sont remote-first et se déroulent en français ou en anglais. Je travaille avec des clients en Europe et en Amérique du Nord, et je cale les entretiens et les restitutions sur le fuseau horaire du client.

Pouvez-vous auditer une proposition fournisseur ou un plan de capacité ?

Oui, c’est une demande fréquente. Je confronte la configuration proposée à la charge qu’elle doit absorber et à ce que le matériel délivre réellement, et je vous dis où elle est sous-dimensionnée, où elle est généreuse, et quelles preuves manquent.

Est-ce uniquement pour les grandes entreprises ?

Non, mais la décision ou le problème doit être suffisamment important pour justifier une mission premium.

Pouvez-vous aider à implémenter les recommandations ?

Oui, mais la revue est conçue pour être autonome. L’implémentation peut être cadrée séparément.

Pourquoi pas simplement embaucher un freelance pour quelques mois ?

Parce que vous n’avez peut-être pas besoin de plus de bras. Vous avez peut-être besoin d’un diagnostic indépendant avant de partir pendant des mois dans la mauvaise direction.