KQL vs. SQL : une bataille de gouvernance agentique ?

Une newsletter data nous a interpellé cette semaine. Philippe Nieuwbourg y posait une question simple en apparence : que gagne-t-on, et que perd-on, à utiliser KQL plutôt que SQL ? La question mérite d'être creusée, parce qu'elle dépasse largement le choix d'un langage de requête.

Elle touche directement à ce que le référentiel Meridian appelle le carburant de toute transformation : la donnée, sa qualité, sa disponibilité, sa gouvernance.

SQL a près de cinquante ans. Conçu à partir des travaux du Dr Codd, il répond à une question précise : comment garantir la cohérence d'une transaction, la mise à jour d'un compte client, l'enregistrement d'une commande. C'est le langage de l'OLTP, celui qui protège l'intégrité d'un système d'information structuré et stable. Il n'a jamais été pensé comme un outil d'analyse à grande échelle, encore moins comme un outil de cybersécurité.

KQL, le Kusto Query Language, est né en 2017 avec Azure Data Explorer, pour répondre à un problème que SQL ne sait pas bien traiter : comment analyser, en quasi temps réel, des milliards de lignes de logs, d'événements de sécurité ou de télémétrie IoT. On le retrouve aujourd'hui au cœur d'Azure Monitor et de Microsoft Sentinel, la plateforme de cybersécurité de Microsoft. Sa syntaxe en pipeline, où chaque étape transforme le résultat de la précédente, est pensée pour l'exploration rapide de volumes massifs et de données faiblement structurées, pas pour la gestion transactionnelle.

Ce n'est donc pas une question de supériorité d'un langage sur l'autre. Ce sont deux outils qui répondent à deux besoins différents, et la plupart des grandes organisations vont devoir vivre avec les deux pendant longtemps. C'est précisément là que le sujet cesse d'être technique.

Dans le cadre Meridian, la donnée est l'un des cinq référentiels indissociables, aux côtés des capacités métier, des processus, des systèmes et de l'organisation. Elle ne se lit jamais isolément, toujours en interaction avec les quatre autres. Introduire KQL dans un système d'information déjà organisé autour de SQL, sans se poser la question de la gouvernance, revient à ouvrir un nouveau référentiel de compétences sans plan de bascule. On ajoute un outil puissant, mais on augmente aussi la surface de fragmentation : deux langages, deux catalogues de compétences, deux façons de documenter une requête, et potentiellement deux définitions légèrement différentes d'un même indicateur métier.

Le diagnostic GAME que nous utilisons chez Gabriel Greenfield part d'un principe simple : la maturité IA d'une organisation n'est jamais la moyenne de ses dimensions, elle est sa dimension la plus faible. Une organisation peut avoir des data scientists brillants et des pipelines KQL impeccables sur sa plateforme de cybersécurité : si la gouvernance des données reste balkanisée entre équipes SQL historiques et nouvelles équipes KQL, c'est cette fragmentation qui déterminera la maturité réelle, pas la performance technique du meilleur outil.

Une donnée non gouvernée est un passif, pas un actif. L'arrivée de KQL en est une illustration concrète. Bien utilisé, en complémentarité assumée avec SQL, il renforce la capacité d'une organisation à détecter des signaux faibles, qu'il s'agisse de fraude, de dérive de performance ou d'incident de sécurité. Mal intégré, sans quality gate de gouvernance, il devient une source supplémentaire de dette silencieuse, invisible jusqu'au jour où deux équipes produisent deux chiffres différents pour la même question posée au COMEX.

Trois recommandations concrètes pour les organisations qui voient KQL s'installer dans leur paysage applicatif, souvent porté par les équipes de cybersécurité ou d'observabilité avant même que la DSI ou la direction data n'en soit informée :

1. D'abord, cartographier. Avant de former qui que ce soit, il faut savoir où KQL est déjà utilisé, par qui, et sur quelles données. Cette cartographie relève de la posture Suggérer : voir ce que les autres ne voient pas encore, six à huit semaines avant que la friction ne devienne visible.

2. Ensuite, arbitrer la complémentarité plutôt que la concurrence. SQL reste le langage de la donnée transactionnelle et de la vérité métier. KQL est un outil d'exploration et de détection sur des volumes massifs et faiblement structurés. Les opposer dans une bataille de religion technologique fait perdre de vue leur complémentarité réelle.

3. Enfin, ancrer la compétence dans la durée. Une organisation qui forme ses analystes à KQL sans processus d'accompagnement structuré verra, comme pour toute nouvelle compétence, l'adoption réelle retomber bien en dessous du taux de déploiement. Ce n'est pas un problème d'outil, c'est un problème d'ancrage.

La question posée par Philippe Nieuwbourg mérite donc une réponse en deux temps. Techniquement, KQL et SQL répondent à des besoins différents et complémentaires. Stratégiquement, la vraie question n'est pas laquelle des deux technologies choisir, mais si votre organisation a la maturité de gouvernance nécessaire pour faire cohabiter plusieurs langages de la donnée sans fragmenter sa vérité métier.

À l'ère de l'IA agentique, où des agents vont eux-mêmes interroger vos données dans l'un ou l'autre langage selon le système qu'ils sollicitent, cette question ne peut plus rester en bas de la pile des priorités du COMEX. Elle mérite un chantier de gouvernance à part entière, avant que la fragmentation ne devienne la norme.

C'est ce type de situation que notre rigueur financière cherche à objectiver dans Meridian dès le cadrage d'une transformation, via la formule ROI = (Gains − TCO) / TCO × 100. Le coût de deux référentiels de requête non réconciliés ne se lit pas sur une ligne budgétaire dédiée, il se lit dans les heures perdues à réconcilier des chiffres a posteriori, et dans la confiance érodée envers les indicateurs qu'on lui présente. C'est un TCO caché, mais bien réel.