Endor Labs veut mieux évaluer les modèles d’IA et les risques du code ouvert

Les projets d’intelligence artificielle ne se résument pas au choix d’un modèle performant. Une entreprise doit aussi vérifier que ses réponses sont utiles dans son contexte, que ses composants logiciels sont fiables et que ses dépendances ne créent pas une porte d’entrée pour une attaque. C’est à l’intersection de ces préoccupations qu’Endor Labs, une start-up spécialisée dans la sécurité du code, présente le 17 octobre 2024 un nouvel outil d’analyse.

L’annonce associe deux sujets que l’on confond souvent : l’évaluation des modèles d’IA, en particulier des modèles linguistiques, et la sécurité de la chaîne d’approvisionnement logicielle. Le premier consiste à mesurer le comportement d’une IA dans un usage donné. Le second revient à examiner les bibliothèques, paquets et composants réemployés pour construire l’application qui héberge cette IA. Les deux sont complémentaires, mais ils ne répondent pas à la même question.

Ce qu’Endor Labs annonce

L’outil présenté par Endor Labs est conçu pour aider les entreprises à analyser les modèles d’intelligence artificielle qu’elles souhaitent employer dans des cas d’usage spécifiques. L’objectif affiché est de fournir une lecture plus précise de leurs performances, de leurs points forts et de leurs limites, plutôt que de se contenter d’une appréciation générale d’un modèle.

Cette nuance compte. Un modèle linguistique peut être convaincant pour résumer un document, mais moins constant lorsqu’il doit extraire une information très précise, respecter une structure de réponse stricte ou traiter un vocabulaire métier. Évaluer un modèle revient donc à confronter ses résultats aux tâches réellement attendues par l’organisation : les requêtes, les documents utilisés, les règles de confidentialité et le niveau d’erreur acceptable.

Endor Labs indique aussi appliquer son analyse aux risques associés aux bibliothèques open source intégrées dans les projets. Les logiciels modernes sont rarement écrits à partir de zéro. Ils assemblent des composants conçus par de nombreuses communautés et éditeurs, parfois indirectement, via les dépendances d’une dépendance. Cette abondance accélère le développement, mais rend difficile la vision complète de ce qui se trouve dans une application.

Évaluer un modèle d’IA, qu’est-ce que cela signifie ?

L’évaluation d’un modèle d’IA ne consiste pas seulement à lui poser quelques questions et à vérifier que ses réponses paraissent plausibles. Dans un cadre professionnel, il s’agit de définir des critères reproductibles : exactitude factuelle, capacité à suivre une instruction, pertinence d’une réponse, régularité des résultats, respect du format demandé ou encore aptitude à signaler une incertitude.

La difficulté est que les résultats d’un modèle génératif ne sont pas toujours identiques d’une requête à l’autre. Une entreprise a donc intérêt à préparer un jeu de tests représentatif de ses usages réels. Pour un service client, il peut s’agir de demandes fréquentes et de cas sensibles. Pour une équipe juridique, de documents contenant des formulations ambiguës. Pour des développeurs, d’exemples de code, de dépendances et de consignes de sécurité.

L’annonce d’Endor Labs met en avant l’emploi de plusieurs modèles d’IA ainsi que d’approches telles que la logique de graphe et le clustering non supervisé, ou regroupement non supervisé. La logique de graphe est utile lorsqu’il faut cartographier des relations complexes : un composant dépend d’un autre, une fonction appelle une autre fonction, ou une bibliothèque est utilisée par plusieurs parties du programme.

Le regroupement non supervisé, lui, désigne une méthode qui cherche des similitudes dans des données sans partir de catégories étiquetées à l’avance. Appliquée à une analyse technique, cette approche peut aider à organiser des éléments qui présentent des comportements ou des caractéristiques comparables. La présentation disponible ne précise toutefois pas comment ces méthodes sont combinées, ni les métriques retenues pour comparer les modèles évalués.

Cette absence de détail appelle à la prudence. Pour juger un outil d’évaluation, les entreprises doivent notamment savoir quels jeux de tests sont pris en charge, si elles peuvent utiliser leurs propres données, comment les résultats sont calculés et si l’analyse peut être reproduite à l’identique.

Pourquoi les dépendances open source sont-elles un enjeu de cybersécurité ?

Le code open source est un pilier du développement logiciel. Il permet aux équipes de réutiliser des bibliothèques plutôt que de reconstruire des fonctions essentielles, par exemple pour gérer des fichiers, communiquer avec une base de données, traiter du texte ou authentifier un utilisateur. Cette réutilisation réduit le temps de développement, mais elle crée également une chaîne de dépendances parfois très longue.

Lorsqu’une vulnérabilité est découverte dans un composant, tous les logiciels qui l’emploient ne sont pas exposés de la même manière. Une bibliothèque peut être présente dans un projet sans que la fonction vulnérable soit appelée. À l’inverse, une faille peut devenir prioritaire si le code concerné est accessible depuis Internet ou peut être atteint par une entrée contrôlée par un attaquant.

C’est pourquoi Endor Labs met l’accent sur les risques présentés comme accessibles et exploitables. Dans ce type d’analyse, l’enjeu n’est pas seulement de produire une longue liste d’alertes. Il est de distinguer les problèmes théoriques des failles qui méritent une intervention rapide, car elles se trouvent réellement sur un chemin d’exécution du logiciel.

Les risques cités dans la présentation comprennent les vulnérabilités connues, les dépendances non sécurisées et les injections de code. Une injection survient lorsqu’une application traite une donnée externe comme une instruction exécutable ou comme une commande. Dans les logiciels intégrant une IA, la surface de risque peut également s’élargir : les applications relient souvent un modèle à des données internes, à des interfaces, à des outils d’entreprise ou à des services tiers.

Ne pas confondre contrôle de l’IA et contrôle du logiciel

L’intérêt d’une plateforme qui relie ces sujets est de permettre à une organisation d’éviter deux angles morts. Le premier serait de valider un modèle uniquement sur la qualité apparente de ses réponses. Le second serait de traiter la sécurité du code sans tenir compte des nouveaux composants, services et flux de données introduits par un projet d’IA.

Dans la pratique, une démarche rigoureuse repose sur plusieurs étapes complémentaires :

• définir les tâches que le modèle doit effectuer et les erreurs inacceptables ;
• constituer des cas de test proches du travail réel, y compris des demandes ambiguës ou malveillantes ;
• inventorier les bibliothèques et composants utilisés par l’application ;
• hiérarchiser les vulnérabilités selon leur accessibilité et leur exploitabilité ;
• vérifier régulièrement les changements apportés au modèle, aux données et aux dépendances.

Pour les petites et moyennes entreprises, le défi est particulièrement concret. Elles disposent rarement d’équipes dédiées pour examiner chaque paquet logiciel ou bâtir leur propre système d’évaluation. Un outil centralisé peut donc simplifier le suivi, à condition que ses alertes soient compréhensibles, qu’il s’intègre aux méthodes de développement existantes et qu’il n’ajoute pas une couche de complexité disproportionnée.

Une promesse environnementale encore peu documentée

Endor Labs évoque également une volonté de limiter l’impact environnemental des projets d’IA, en réduisant l’empreinte associée à l’IA générative. Le sujet est important : l’entraînement et l’utilisation de modèles peuvent nécessiter des ressources de calcul conséquentes, surtout lorsque les requêtes sont nombreuses ou que les modèles employés sont particulièrement volumineux.

Pour autant, cette ambition ne permet pas à elle seule de mesurer un bénéfice environnemental. La présentation ne fournit pas d’indicateur chiffré, de méthode de calcul, de comparaison avant et après usage, ni de détail sur les mécanismes qui permettraient de réduire la consommation de ressources. Il serait donc prématuré d’attribuer à l’outil un impact quantifié sur l’empreinte carbone des projets.

Les entreprises qui veulent intégrer ce critère à leur stratégie peuvent déjà s’interroger sur des choix très concrets : utiliser un modèle adapté plutôt que systématiquement le plus grand disponible, réduire les requêtes inutiles, limiter les duplications de traitements et mesurer les ressources mobilisées. L’évaluation des performances peut y contribuer, si elle aide à sélectionner le modèle le plus sobre capable d’atteindre le niveau de qualité requis.

Ce que l’annonce ne permet pas encore de vérifier

L’outil d’Endor Labs est présenté comme accessible aux organisations de différentes tailles et comme susceptible d’accompagner leur montée en compétence en matière de sécurité. La présentation mentionne aussi un support aux utilisateurs, avec des ressources éducatives, des tutoriels et une assistance technique.

Plusieurs éléments déterminants restent néanmoins absents des informations disponibles au 17 octobre 2024. Aucun tarif n’est précisé. Les conditions d’accès, les langages de programmation et écosystèmes couverts, le mode d’hébergement, la gestion des données analysées ou les éventuelles limites d’intégration ne sont pas détaillés. Il n’est pas non plus fait état de résultats comparatifs permettant d’évaluer l’efficacité de l’outil face à d’autres solutions.

Ces réserves ne diminuent pas l’intérêt du problème traité. Elles rappellent simplement qu’une promesse de cybersécurité doit être examinée à l’aune de critères opérationnels. Avant tout déploiement, une organisation doit vérifier si l’outil couvre bien ses environnements, si les alertes sont exploitables par ses équipes et si les informations collectées respectent ses exigences de confidentialité.

Ce qu’il faut surveiller

L’arrivée d’applications fondées sur l’IA transforme progressivement la sécurité logicielle. Les équipes ne doivent plus seulement connaître les composants de leur application : elles doivent aussi comprendre quel modèle est utilisé, sur quelles données il s’appuie, quelles actions il peut déclencher et comment ses réponses sont contrôlées.

Pour Endor Labs, le défi sera de démontrer que son approche apporte une priorisation réellement utile, plutôt qu’un volume supplémentaire d’alertes. La capacité à différencier une dépendance simplement présente d’une vulnérabilité effectivement atteignable sera centrale. De même, l’évaluation des modèles n’a de valeur que si elle reflète les situations concrètes rencontrées par les utilisateurs.

À plus long terme, les entreprises chercheront des outils capables de réunir plusieurs visions : qualité des résultats de l’IA, inventaire des composants, sécurité du code, gouvernance des données et suivi des changements. L’annonce d’Endor Labs illustre cette évolution : dans un projet d’IA, la confiance ne se décrète pas au moment de choisir un modèle. Elle se construit tout au long du cycle de développement et d’exploitation.