Best Of Tech #74

Le MCP, vers un HTTP des agents ?

par Olivier BELTRAMO-MARTIN

Le MCP, encore un acronyme de plus ?

Si vous suivez un petit peu l’actualité tech IA, vous avez sûrement été abreuvé (peut-être un peu trop) de ce nouveau concept à la mode : le Model Context Protocol – MCP pour ceux qui n’avaient pas assez d’acronymes en tête. Est-ce que ça révolutionne votre stack IA ? Pas forcément.

Les agents IA, entre raisonnement et interconnexion

Le MCP s’inscrit dans le contexte des agents IA qui sont des LLMs (ah pardon, des Large Language Models !) en capacité d’utiliser des outils distants, comme des moteurs de recherche, des agendas ou encore des applications de chat, et surtout d’être en mesure d’identifier quels outils utiliser ou non en fonction de la tâche via un raisonnement.

Une dépendance aux fournisseurs et aux APIs

La difficulté est que la façon de transmettre ces outils au LLM dépend… du LLM, ou plus exactement de l’API qui l’expose. Ainsi, en fonction du fournisseur de modèle que vous utilisez, qu’il soit hébergé en local (vous êtes team ollama ou vLLM ? ) ou par un tiers, il est nécessaire d’adapter l’interface entre les outils et le fournisseur.

Le MCP, un protocole pour unifier l’accès aux outils

MCP propose alors un standard de communication entre les outils et les LLM – enfin surtout Claude Desktop développé par Anthropic à l’origine de ce protocole –  à partir d’une architecture client-serveur où l’application hôte (l’agent IA) accède à des outils et des données via des serveurs MCP, chacun associé à un service.

Un standard utile… mais pas pour tout le monde

L’idée d’un standard est séduisante mais nécessite d’être adoptée largement pour en mériter le titre et n’offre une utilité que sur un périmètre limité. Typiquement, c’est intéressant si vous travaillez sur un produit interopérable capable de se connecter à plusieurs fournisseurs de LLM. Ça l’est moins si vous avez choisi un fournisseur unique sur un projet puisque vous pouvez toujours connecter le LLM à des outils et des données sans passer par le MCP.

TL;DR : multi-LLM -> MCP, mono-LLM -> API.

Tester OpenID Connect et SAML tout en s’amusant

par Laurent Meunier

OpenID Connect et SAML : un terrain de jeu (presque) fun

Je vous le concède, le niveau d’amusement engendré par l’évocation de noms comme OpenID Connect ou SAML reste très subjectif, mais on s’amuse comme on peut/veut, non ? 😄

En tout cas, j’étais à la fois heureux et surpris d’apprendre l’existence de projets en ligne jouant le rôle de clients OIDC ou SAML permettant de tester et comprendre un peu mieux ces protocoles. Heureux, car c’était l’occasion d’en apprendre encore un peu plus. Et surpris, car je suis passé à côté de ces projets tout ce temps sans m’en rendre compte !

Bref, trêve de bavardage, venons en au concret.

Tester OpenID Connect facilement

Pour OpenID Connect, vous aurez besoin d’un Identity Provider (IDP) accessible depuis Internet. Keycloak remplit très bien ce besoin, mais vous pouvez utiliser l’outil que vous voulez tant qu’il sait causer en OIDC.

• La suite se passe sur openidconnect.net, ce site joue le rôle d’un client OIDC et va vous permettre de dérouler toutes les étapes de l’authentification avec quelques explications et détails au passage. 
• Vous prendrez bien soin de cliquer sur « Configuration » pour aligner la configuration du site avec un client OIDC que vous créerez dans votre IDP. Et ensuite, il n’y a plus qu’à cliquer sur « START » et à se laisser guider.
• Petit bonus au passage pour la mention de jwt.io, site très pratique pour l’inspection de JSON Web Token (JWT) et vérifier ainsi le contenu de l’id_token (claims et valeurs).

Et pour SAML, comment ça marche ?

Pour SAML, on est globalement sur le même principe : un IDP causant le SAML est nécessaire + utilisation d’un site externe qui joue le rôle d’un client SAML. Le site en question est sptest.iamshowcase.com.

Deux modes de fonctionnement sont disponibles : IDP initiated et SP initiated. Dans tous les cas, la création d’un client SAML dans votre IDP est nécessaire, cette création peut se faire à partir des métadonnées fournies directement sur le site.

Petit bonus pour SAML : contrairement à OIDC, il n’est pas nécessaire que l’IDP soit accessible depuis Internet, vous pouvez tester avec un Keycloak sur http://localhost:8080 ce qui devrait vous simplifier la vie.

Et voilà ! Amusez-vous bien 😉

Make security great again

par Thomas Broyer

Un coup de tonnerre dans la cybersécurité mondiale

Ce mardi 15 avril, le MITRE, organisme à but non lucratif (501c), a annoncé que le Department of Homeland Security (DHS), probablement sous l’impulsion du DOGE, n’avait pas renouvelé le contrat finançant les programmes CVE et CWE et arrivant à échéance le lendemain.

Stupeur dans l’auditoire, puisque le monde entier repose sur cette base de données de vulnérabilités. Celle-ci est exportée à la va-vite sur GitHub de peur qu’elle disparaisse purement et simplement (le MITRE ayant laissé entendre que les serveurs pourraient être mis hors ligne dès le mercredi). Un site pour une CVE Foundation est créé, apparemment par des membres du bureau du programme CVE (mais sans les nommer, et sans jamais aucune confirmation ou infirmation d’aucun d’entre eux), pour abstraire la gestion des CVE du gouvernement américain et garantir sa pérennité.

Une reconduction in extremis, mais des conséquences durables

À la dernière minute, le DHS annonce finalement reconduire le contrat pour 11 mois supplémentaires (on a pu aussi noter en passant que le message du MITRE à ses partenaires, annonçant la reconduction du contrat, utilisait la dénomination “CVE®” rappelant ainsi que c’est une marque déposée au registre du commerce américain, probablement en réaction à cette CVE Foundation), mais le mal est fait : la confiance est érodée et le monde semble s’accorder sur la nécessité de revoir le système.

Vers des alternatives européennes et décentralisées

Ainsi, le CIRCL (l’équivalent de notre ANSSI nationale au Luxembourg) en a profité pour lancer gcve.eu, un système décentralisé d’identification des vulnérabilités (la seule centralisation étant l’attribution d’un numéro d’émetteur ; le 0 étant réservé pour la compatibilité avec le programme CVE, et le 1 attribué au CIRCL).

L’ENISA, l’agence de cybersécurité de l’Union Européenne qui coordonne les CERT/CSIRT nationaux, dont l’ANSSI et le CIRCL, a de son côté (re)mis en ligne sa base de données EUVD qui agrège diverses bases de vulnérabilités (dont les CVE). Celle-ci était attendue d’ici l’entrée en vigueur de la directive NIS2 pour laquelle elle a été créée, mais ce timing ne peut pas n’être qu’une coïncidence.

Panorama réglementaire

par Xavier Calland

NoLimitSecu : le podcast cybersécurité à ne pas manquer

NoLimitSecu est un podcast indépendant dédié à la cybersécurité.

L’épisode #494, paru le 16 mars 2025, a pour titre Panorama Réglementaire et passe en revue les différentes réglementations en place ou à venir autour de la cybersécurité, avec une grosse partie sur la directive NIS2, (mais aussi Dora, CRA et d’autres)

Pour rappel, la directive NIS2 vise à renforcer la cybersécurité dans l’Union Européenne au travers de réglementations et d’exigences en matière de cybersécurité applicables à un large éventail d’organisations et d’entités dans l’Union Européenne (avec également des obligations pour leurs prestataires de services).

Ce que je retiens de cet épisode du podcast ?

Certes, les problématiques de sécurité logicielle ne datent pas d’aujourd’hui, cependant ces sujets sont trop souvent mis de côté (il n’y a qu’à regarder les failles et vulnérabilités régulièrement exploitées).

Il est grand temps de mettre un incrément sur la cybersécurité et d’intégrer les questions de sécurité logicielle au cœur des processus. Les réglementations arrivent et, même si elles ne sont pas encore en vigueur, ce n’est plus le temps d’attendre ! Il faut voir là une opportunité à saisir et prendre part au mouvement.