LykConsulting
Réalisations
Plateformes d'observabilité et d'analyse de performance conçues pour un grand groupe d'assurance : de la production de la donnée à sa restitution, jusqu'à l'automatisation de l'analyse par intelligence artificielle.
Grand groupe d’assurance
2024-2026
Observability AI — analyse de performance automatisée
Assistant IA
Une analyse de performance mobilisait un expert plusieurs heures : ouvrir l'outil de logs, croiser l'APM, chercher les changements dans l'ITSM, vérifier les bases de données, puis remettre le tout en forme. L'application industrialise cette démarche : l'incident est décrit en langage naturel, la chaîne d'investigation s'exécute, un rapport PDF exploitable en sort.
- Routage déterministe des intentions (stabilité, RCA applicatif, ITSM, réseau, mainframe, base de données)
- Exécution de « piliers » d’analyse chaînés, avec baseline automatique à J-7 et corrélation des changements
- Garde-fou anti-hallucination : toute affirmation du rapport est adossée à une mesure réellement collectée
- Historique des conversations, bibliothèque de rapports, suivi des coûts LLM, mode expert
- Diffusion multi-canal : rapport PDF brandé, carte adaptative sur la messagerie d’équipe, e-mail
Résultats
- Analyse ramenée de plusieurs heures d’expert à quelques minutes
- Le modèle de langage n’accède jamais aux données brutes : il orchestre des outils, il ne les remplace pas
- Connecteurs temps réel vers cinq systèmes sources
- Python
- FastAPI
- PostgreSQL
- React
- TypeScript
- SSE
- LLM (tool-calling)
- Docker Compose
Grand groupe d’assurance
2025-2026
Observability Inventory — référentiel vivant du parc applicatif
Référentiel & cartographie
Impossible de répondre simplement à « cette application est-elle supervisée ? » ou « qu'est-ce qui tombe si ce composant tombe ? ». Les dépendances vivaient dans des cartographies dessinées à la main, incomplètes et vite périmées. L'application recompose ce référentiel automatiquement et le confronte en permanence à la réalité des données.
- Carte de dépendances force-directed développée sur mesure en SVG (zoom, déplacement, isolation d’un nœud)
- Enrichissement automatique depuis l’APM (relations d’appel observées) et depuis les référentiels déclaratifs
- Matrice de couverture d’outillage : APM, stabilité, qualité, logs, infrastructure
- Audit nocturne direct — ce qui est déclaré existe-t-il réellement ?
- Audit nocturne inverse — qu’est-ce qui produit des données sans être référencé ? Détection des gisements de logs orphelins
Résultats
- 113 fiches applicatives et plus de 750 dépendances maintenues automatiquement
- Statut de stabilité rafraîchi toutes les 5 minutes
- Le référentiel ne peut plus dériver : deux audits croisés le confrontent chaque nuit aux données réelles
- Python
- FastAPI
- JavaScript
- SVG
- YAML
- cron
Grand groupe d’assurance
2025-2026
Observability Monitoring — disponibilité de bout en bout
Supervision applicative
Les sondes techniques et les scénarios de navigation produisaient un volume important d'événements, mais aucune restitution transverse : impossible de dire quelle application était réellement disponible, ni de descendre jusqu'au test technique en échec. L'application reconstruit cette chaîne, du taux de disponibilité global jusqu'à la sonde défaillante.
- Arbre application → serveur → contexte web → sonde, avec interrogation temps réel au clic
- Heatmaps agrégées côté moteur de recherche pour tenir la volumétrie
- Filtres transverses par période (1 h à 30 j), application et population d’utilisateurs
- Sonde live protégée contre le SSRF par liste blanche d’hôtes
Résultats
- 43 applications supervisées, 69 scénarios et 327 sondes techniques
- Règle de disponibilité définie avec le métier : une sonde technique secondaire en échec ne déclare plus une application indisponible
- Python
- FastAPI
- JavaScript
- JSON-RPC
- XML
Grand groupe d’assurance
2026
Portail unifié Observabilité & Performance
Plateforme
Les outils de l'équipe étaient dispersés sur une dizaine de ports d'un serveur, chacun avec son URL à mémoriser — et une partie de ces ports était filtrée depuis les postes clients : l'outil tournait mais restait injoignable. Le reverse proxy, lui, était mutualisé avec quatorze applications d'autres équipes : impossible de le réécrire.
- Contrainte structurante : ne modifier aucune ligne de configuration existante, le proxy étant partagé
- Autorisation insérée avant la règle de blocage terminale, plutôt que modification de cette règle critique
- Désambiguïsation par en-tête Referer pour les applications appelant des ressources à la racine
- Encapsulation d’une application au routage côté client, qui perdait son préfixe derrière le proxy
- Bascule en URL relative d’un outil qui pointait vers un port filtré depuis les postes
- Patches de configuration idempotents, sauvegarde horodatée et validation syntaxique avant tout rechargement
Résultats
- 18 outils accessibles en un clic depuis un seul écran, sans défilement
- Zéro ligne de configuration des équipes tierces impactée
- Procédure de réinstallation scriptée, configuration de référence versionnée
- HAProxy
- HTML/CSS
- Python
- PowerShell
Grand groupe d’assurance
2026
Tour de contrôle quotidienne — périmètre Épargne
Tour de contrôle
Le rituel de production quotidien du périmètre Épargne s'appuyait sur des sources dispersées. L'application les consolide en une revue unique, conçue pour être lue en séance.
- Sept visions en onglets : alerting, stabilité, disponibilité, applicative, performance, partenaires, suivi
- Agrégation de trois familles de sources : sondes de supervision, index de stabilité calculé à 5 minutes, métriques d’infrastructure
- Comparaison systématique du jour à J-7
- Taux de disponibilité décliné par population d’utilisateurs
- Espaces d’analyse d’impact et de scoring
Résultats
- Support unique de la revue quotidienne de production
- Suivi de la performance transactionnelle, de la latence réseau inter-sites et de l’expérience poste de travail dans un même écran
- Splunk Cloud
- SPL
- Dashboard Studio
Grand groupe d’assurance
2025-2026
Contrôle qualité des flux réglementaires Solvabilité 2
Qualité de donnée
Les flux de données réglementaires alimentant la chaîne Solvabilité 2 devaient être contrôlés en qualité et en délivrabilité, à une volumétrie que les approches classiques ne tiennent pas.
- Modèle de données dédié interrogé en mode accéléré, pour tenir des volumétries de l’ordre du milliard d’événements
- Trois niveaux de restitution : vision sommaire, consolidée, et consolidée comptable
- Croisement couple applicatif × flux × statut de délivrabilité × décompte des contrôles
- Refonte de l’indicateur de délivrabilité : suppression des faux négatifs induits par des jointures à fenêtre temporelle figée, au profit d’une construction par référentiel juste pour toute mensuelle passée
Résultats
- Jusqu’à 16,5 millions de contrôles suivis sur un seul flux, dont les écarts sont isolés ligne à ligne
- Faux négatifs de délivrabilité éliminés — la cause était structurelle, pas paramétrique
- Splunk Cloud
- SPL
- tstats
- Dashboard Studio
Grand groupe d’assurance
2025-2026
Analyse de charge mainframe et anticipation du bridage
Mainframe
La consommation du mainframe est plafonnée contractuellement. Le franchissement du plafond déclenche un bridage de la machine, dont l'effet se voit immédiatement sur les temps de réponse applicatifs — mais se constatait après coup.
- Chaîne complète d’analyse de la charge : santé temps réel, journée type, détail des travaux batch, diagrammes de Gantt des chaînes
- Statistiques par programme, performance des transactions transactionnelles, indicateurs de niveau de service
- Comparaison continue de la consommation des partitions logiques à la limite contractuelle
- Prédiction à 30 intervalles anticipant le franchissement du plafond
Résultats
- Le bridage devient anticipable au lieu d’être constaté : l’équipe agit avant l’impact applicatif
- Pourcentage de charge par partition rafraîchi à la seconde
- Splunk Cloud
- SPL
- z/OS
- enregistrements SMF
Grand groupe d’assurance
2026
Passerelles d’extraction — sortir la donnée vers les systèmes tiers
Industrialisation
La plateforme d'observabilité est excellente pour calculer, mais les consommateurs de ces calculs n'y sont pas : une chaîne d'alimentation attend des fichiers déposés sur un serveur, une équipe FinOps travaille dans un espace documentaire. Deux batchs jouent le rôle de passerelle sortante, sans intervention humaine.
- Un seul moteur générique, N rapports : aucun cas d’usage n’est codé en dur, tout est paramétré par l’environnement
- Requêtes maintenues dans la plateforme et appelées par référence : les faire évoluer n’impose aucune livraison
- Protection anti-doublon par empreinte SHA-256 du jeu de résultats — la chaîne aval ne retraite jamais deux fois la même donnée
- Protocole de dépôt respecté à la lettre : données, drapeaux de complétude et journal, pour que l’ordonnanceur aval ne consomme qu’un fichier complet
- Extraction paginée par tranches, pour dépasser sans erreur silencieuse les plafonds de restitution de l’API cible
- Dégradation élégante en trois niveaux : proxy injoignable, jeton non délivré ou téléversement en échec conduisent tous au même repli par courriel
Résultats
- Le livrable arrive quoi qu’il arrive — c’est le point clé de conception : aucun échec n’est silencieux
- Batch horaire dont la source ne change qu’une fois par jour : aucun retraitement inutile en aval
- Python
- SDK Splunk
- SFTP
- API Graph
- OAuth2
- Bash
- cron
Grand groupe d’assurance
2025-2026
Morning Check automatisé — santé du SI en une carte
ChatOps
La validation quotidienne des performances du SI reposait sur une revue manuelle. Elle avait deux limites : elle mobilisait du temps expert chaque matin, et elle intervenait trop tôt pour observer la montée en charge réelle des utilisateurs. Le contrôle est industrialisé et diffusé automatiquement dans la conversation d'équipe, deux fois par matinée, dont une après la montée en charge.
- Un statut global, calculé à partir de six domaines : applicatif, base de données, poste de travail, serveurs web, assistance et réseau
- Chaque domaine porte ses propres règles de qualification, en OK / Warning / KO
- Deux familles de seuils combinées : comparaison à la semaine précédente pour détecter la dérive, et seuils absolus sur une heure glissante pour détecter l’incident
- Règle de disponibilité applicative fondée sur un indice de stabilité, pas sur une sonde isolée
- Carte adaptative avec détails repliables et liens directs vers les tableaux de bord de niveau 2
- Diffusion par automate, sans intervention humaine
Résultats
- Revue matinale de plusieurs domaines ramenée à la lecture d’une seule carte
- Deuxième passage programmé après la montée en charge : les dégradations qui n’apparaissaient qu’en charge sont désormais vues le matin même
- Passage d’un contrôle déclaratif à un contrôle mesuré, avec des seuils explicites et discutables
- Splunk Cloud
- SPL
- Power Automate
- Adaptive Card 1.4
- Teams
Grand groupe d’assurance
2024-2026
Pilotage FinOps de la plateforme de données
FinOps
La licence de la plateforme de données est facturée au volume ingéré. Une dérive de volumétrie se découvrait sur la facture, donc trop tard pour être arbitrée. Il fallait la voir venir.
- Exploitation des journaux internes de l’indexeur pour suivre la consommation jour par jour
- Trois niveaux de lecture : consommation totale, répartition par couple source × index, détail tabulaire
- Outil de référence pour arbitrer les entrées de données avant qu’elles n’impactent le contrat
Résultats
- La dérive de volumétrie devient visible et arbitrable avant facturation
- Décisions d’ingestion appuyées sur une mesure, plus sur une estimation
Grand groupe d’assurance
2025
Supervision d’une chaîne métier 100 % conteneurisée
Kubernetes & RPA
Une chaîne de traitement de dossiers de prévoyance, entièrement conteneurisée et terminée par un robot logiciel, ne produisait aucune télémétrie applicative classique. La seule matière disponible était le journal des conteneurs.
- Supervision reconstruite exclusivement à partir des logs de conteneurs, filtrés par étiquette de référentiel
- Entonnoir métier matérialisé étape par étape, chaque volumétrie obtenue par reconnaissance d’un motif précis dans le journal du composant correspondant
- Deux compteurs d’anomalie distincts : rejets métier et échecs techniques
- Extension au pilotage du run et aux extractions associées
Résultats
- Une chaîne jusque-là aveugle devient mesurable de bout en bout, du dépôt au robot
- Les pertes de dossiers se localisent à l’étape près, au lieu d’être constatées globalement
- Splunk Cloud
- SPL
- Kubernetes
- RPA
Grand groupe d’assurance
2025-2026
Contrôle automatisé de conformité des bases de production
Conformité
Le paramétrage des instances de base de données de production dérivait au fil des interventions, sans que personne ne puisse dire de combien ni où. Les écarts se découvraient à l'occasion d'un incident.
- Collecte du paramétrage de chaque instance, puis confrontation à une valeur attendue tenue dans un référentiel
- Taux de conformité par instance et répartition des écarts par niveau de criticité
- Détail ligne à ligne : paramètre, valeur courante, valeur attendue
- Vues complémentaires : analyse par instance, monitoring, parallélisme des index, statistiques
Résultats
- La dérive de paramétrage devient un indicateur suivi, au lieu d’une découverte d’incident
- Écarts hiérarchisés par criticité : l’équipe traite ce qui compte d’abord
- Splunk Cloud
- SPL
- DB Connect
- Oracle
Grand groupe d’assurance
2024-2025
Compte rendu de performance d’une filiale, du siège aux agences
Filiale
L'intégration d'une filiale au système d'information du groupe devait être pilotée sur des faits : les utilisateurs de la filiale travaillaient-ils dans des conditions comparables à celles du groupe, au siège comme en agence ?
- Croisement de deux mondes : le référentiel des utilisateurs de la filiale, enrichi de leur affectation, et la télémétrie des transactions applicatives
- Indicateur de ressenti utilisateur calculé sur les transactions rapides
- Sept restitutions : vue d’ensemble, activité informatique, poste de travail, synthèse, investigation, agences, comparaison d’activité
- Suivi du statut de bascule et investigation des écarts de performance entre les deux périmètres
Résultats
- Plus de 700 utilisateurs suivis, siège et agences distingués
- Le pilotage de l’intégration s’appuie sur des mesures d’expérience réelle, pas sur des déclarations
- Splunk Cloud
- SPL
- Dashboard Studio
- Citrix/VDI
