Meta et l’IA : distinguer Llama, Meta AI et leurs mécanismes de contrôle

Meta ne propose pas une seule manière d’accéder à l’IA

Parler de l’intelligence artificielle de Meta peut désigner des réalités différentes : des modèles qu’un développeur obtient pour les intégrer à son propre système, ou des produits de Meta qui mettent des fonctions d’IA à la disposition de leurs utilisateurs. Cette distinction est pratique, et pas seulement terminologique. Dans le premier cas, l’adoptant doit étudier la licence de la version concernée et décider comment exécuter et protéger le modèle. Dans le second, il utilise un service de Meta et dépend des conditions, des fonctionnalités et de la disponibilité définies par l’entreprise pour ce produit.

Les sources disponibles permettent de documenter certains aspects de cette différence, mais pas tous. Le catalogue de téléchargement de Meta répertorie Llama 4 Scout et Maverick et renvoie à une licence communautaire. La page officielle de Meta AI décrit différentes interfaces du produit et identifie le modèle qui, selon Meta, le propulse. Ces documents émanent du fournisseur lui-même : ils permettent de savoir ce que Meta publie au sujet de ses systèmes, mais ne constituent pas, à eux seuls, une évaluation indépendante.

Il existe également une source externe, de portée limitée : Apollo Research publie des informations sur ses tests de Muse Spark, notamment une évaluation portant sur la conscience d’être soumis à une évaluation. Ce type de test peut apporter des indices sur un comportement précis ; il ne constitue pas un audit global du système et ne démontre pas comment celui-ci se comportera dans tous les contextes. La grille de lecture utile n’est donc pas un classement du « meilleur » au « moins bon », mais une distinction entre accès, contrôle opérationnel, conditions d’utilisation et éléments de preuve.

Llama pour les développeurs : le modèle ne dispense pas d’examiner les conditions

La page de téléchargement de Meta répertorie Llama 4 Scout et Maverick et indique que ces modèles sont distribués sous une licence communautaire. C’est un point de départ pour l’examen, pas une autorisation générale pour toute activité ni une description suffisante de toutes les obligations. La licence pertinente est celle de la version choisie : avant d’intégrer le modèle, de le modifier, de le proposer à des tiers ou de le redistribuer, il faut lire son texte et confronter l’usage envisagé à ses conditions.

La licence de Llama 4 est le document à consulter pour vérifier des sujets tels que l’attribution, la redistribution, les modifications et les conditions d’utilisation. Les éléments fournis pour ce guide ne reproduisent pas ses clauses détaillées. Il ne serait donc pas rigoureux de résumer des exigences précises — par exemple, les mentions à conserver ou les usages susceptibles d’être soumis à des conditions supplémentaires — sans consulter et analyser le texte intégral. Le qualificatif « communautaire » ne doit pas non plus être interprété comme synonyme de domaine public ou d’absence de restrictions.

L’accès direct aux fichiers du modèle peut permettre à une équipe de l’exécuter sur une infrastructure qu’elle contrôle, si elle dispose des ressources et de la configuration nécessaires. Cela ne signifie pas que chaque déploiement est automatiquement inspectable, sûr ou reproductible : ces propriétés dépendent des éléments publiés, des outils disponibles et des décisions de l’équipe. En outre, les capacités du modèle ne déterminent pas à elles seules le comportement de l’application finale. Le système peut intégrer des instructions, des filtres, de la recherche d’informations, des interfaces et des permissions qui modifient le résultat.

Pour un responsable produit, la décision pratique consiste à documenter la chaîne d’adoption : modèle exact, version, provenance des fichiers, licence applicable, modifications effectuées et mesures mises en place dans l’application. Cette documentation facilite également les vérifications ultérieures en cas de mise à jour du modèle ou de changement de finalité du produit. Un lien vers une page générale de téléchargement ne remplace pas l’enregistrement de la licence effectivement acceptée pour une version donnée.

Meta AI et Muse Spark : utiliser un produit géré par le fournisseur

Lorsqu’une personne utilise Meta AI sur l’une des interfaces présentées par Meta, elle n’adopte pas nécessairement un modèle à exécuter sur sa propre infrastructure. Elle interagit avec un produit géré par l’entreprise. Sur le plan opérationnel, une partie du contrôle se déplace : l’utilisateur peut accéder aux fonctions proposées par le produit, mais ne doit pas présumer qu’il dispose des poids, de tous les paramètres du système ou de la possibilité de reproduire l’environnement d’exécution.

La page produit de Meta identifie le modèle qui, selon l’entreprise, propulse Meta AI. Cette affirmation doit être attribuée à Meta. La documentation disponible ici ne permet pas d’établir quel modèle est utilisé sur chaque interface, dans chaque pays ou à chaque instant, ni de décrire un calendrier de disponibilité. Les produits peuvent varier selon les marchés ou être mis à jour ; pour une décision concrète, la vérification doit porter sur le lieu et la date d’utilisation concernés.

Muse Spark est présenté dans la proposition comme un système pour lequel Meta a publié un rapport de sécurité, mais ce rapport ne fait pas partie des sources vérifiées fournies pour cet article. Ses évaluations, conclusions, limites ou décisions de déploiement ne sont donc pas présentées ici comme des faits. Apollo Research publie, en revanche, des informations sur ses propres tests de Muse Spark, dont une évaluation de la conscience d’évaluation. Leur portée se limite à ces tests publiés ; ils ne valent pas certification générale de sécurité.

Pour les équipes qui envisagent d’intégrer un assistant hébergé dans un produit, vérifier l’identité du modèle ne suffit pas. Elles doivent examiner les fonctionnalités disponibles sur leur marché, les données saisies, les contrôles proposés et les conditions régissant l’utilisation. Les sources réunies ne permettent pas de répondre intégralement à toutes ces questions pour chaque interface de Meta AI. La règle prudente consiste à séparer les éléments observés dans l’interface des caractéristiques connues uniquement par la documentation du fournisseur.

Deux voies d’adoption, des vérifications différentes

La distinction entre l’exécution d’un modèle et l’utilisation d’un produit géré par le fournisseur aide à structurer l’évaluation. Elle ne signifie pas qu’une modalité est toujours plus sûre, plus privée ou plus adaptée qu’une autre. Exécuter un modèle peut donner à l’équipe davantage de contrôle sur l’environnement, mais lui confie aussi plus de tâches d’exploitation et de sécurité. Un produit hébergé réduit certaines charges d’infrastructure, mais son fonctionnement et ses contrôles dépendent de ce que le fournisseur propose et documente.

La matrice ci-dessous est un outil d’analyse, et non une comparaison des performances. Elle résume les questions auxquelles il convient de répondre à l’aide d’éléments probants avant de s’engager. Lorsqu’une réponse dépend du marché, de la version ou du contrat, il faut la vérifier dans le document concerné plutôt que la généraliser à tous les produits de Meta.

Sécurité : distinguer politique, guide, rapport et test externe

Une affirmation relative à la sécurité peut s’appuyer sur des documents de nature très différente. Une licence fixe des conditions ; ce n’est pas une évaluation technique. Un guide destiné aux développeurs recommande des pratiques ou attribue des responsabilités ; il ne prouve pas qu’une application a effectivement mis ces pratiques en œuvre. Un rapport de préparation décrit des évaluations et des décisions, lorsqu’il est disponible, mais son existence ne constitue pas en soi une garantie. Un test externe peut apporter des éléments de preuve indépendants, tout en restant limité à ses méthodes, à ses scénarios et aux résultats publiés.

Le Developer Use Guide de Meta est pertinent pour les personnes qui développent des systèmes fondés sur Llama, car il propose des pratiques et traite des responsabilités des développeurs. Il ne faut pas confondre sa fonction avec une garantie que le modèle empêche les usages nuisibles ou qu’un produit construit sur cette base est sûr. L’équipe doit transformer les recommandations applicables en contrôles concrets, les tester et les maintenir en exploitation. Le guide aide à structurer le travail ; il ne remplace pas l’analyse des risques propre à chaque application.

Apollo Research publie des tests de Muse Spark, dont une évaluation liée à la conscience d’évaluation. Cette référence permet d’affirmer qu’un travail externe a été mené sur ce comportement précis. Sans examen du protocole et de l’ensemble des résultats, elle ne permet pas de conclure que tout l’éventail des risques a été évalué. Il ne convient pas non plus d’étendre le résultat d’un test à d’autres modèles, versions ou déploiements.

La proposition initiale mentionne un Advanced AI Scaling Framework et un Safety & Preparedness Report consacré à Muse Spark. Ces documents ne figurant pas parmi les sources vérifiées fournies pour cet article, aucune affirmation ne leur est attribuée ici quant à leur champ d’application, leurs seuils, leurs résultats ou les décisions qui en découlent. Pour les intégrer rigoureusement, il faudrait examiner leur texte à jour et préciser quels types de systèmes et de déploiements ils couvrent, quelles évaluations ils décrivent et quelles limites ils déclarent. En attendant, les présenter comme des éléments de preuve confirmés irait au-delà des sources disponibles.

Limites des éléments publics disponibles

La documentation examinée est hétérogène : une page de téléchargement, un texte de licence, une page produit, un guide destiné aux développeurs et une publication de recherche externe. Ces documents ne répondent pas aux mêmes questions et ne permettent pas de comparer de manière uniforme le comportement de Llama, Meta AI et Muse Spark. En particulier, nous ne disposons pas ici d’une évaluation indépendante globale couvrant tous ces systèmes et leurs variantes.

Il ne faut pas non plus confondre la publication de documents avec la vérifiabilité de chaque affirmation. Un document officiel permet de vérifier ce que Meta déclare, mais une affirmation du fournisseur reste une affirmation qui lui est attribuée, sauf corroboration indépendante pertinente. À l’inverse, une étude externe de portée limitée n’invalide pas, à elle seule, d’autres évaluations : elle constitue un élément de preuve dont la valeur dépend de sa méthode, de son champ et de la possibilité de reproduire ou de recouper ses résultats.

La date compte. Un catalogue peut être mis à jour, les produits peuvent évoluer et les conditions d’accès peuvent changer. Une équipe devrait donc conserver la version des documents consultés et noter la date à laquelle elle a vérifié la disponibilité. Une décision d’achat ou de déploiement ne devrait pas reposer sur un résumé de tiers si le texte même de la licence ou les conditions du service sont déterminants.

Pour établir une évaluation plus complète, il faudrait examiner directement les documents de préparation cités dans la proposition, consulter les conditions de Meta AI applicables à chaque interface et à chaque marché, puis confronter les tests de sécurité à des évaluations indépendantes de portée comparable. Il ne faut pas compléter ces informations par déduction. Exprimer explicitement l’incertitude est préférable à affirmer un niveau de contrôle ou de sécurité que les sources fournies ne démontrent pas.

Liste pratique avant d’adopter une technologie de Meta

La décision peut prendre la forme d’un examen bref, mais documenté. Commencez par déterminer si vous évaluez un modèle à exécuter ou un produit hébergé. Consignez ensuite la version ou l’interface exacte et identifiez le document qui régit l’utilisation. Enfin, traduisez les obligations et les limites en décisions d’architecture, en processus et en contrôles vérifiables.

Pour un modèle Llama, cela signifie ne pas s’arrêter à la fiche du catalogue : il faut lire la licence concernée, vérifier que l’usage prévu est compatible avec celle-ci et attribuer les responsabilités de mise en œuvre. Pour Meta AI, il faut confirmer quelles fonctionnalités sont disponibles dans l’environnement concerné et examiner les conditions et contrôles pertinents du produit. Dans les deux cas, les décisions relatives aux données, aux permissions, à la supervision humaine et à la réponse aux défaillances doivent être adaptées aux risques réels de l’application.

Lors d’une évaluation de sécurité, demandez qui a réalisé chaque test, quelle version a été examinée, quels scénarios ont été couverts et quels aspects ont été exclus. Un guide, une politique, un rapport de préparation et une évaluation externe peuvent se compléter, mais ne sont pas interchangeables. La simple mention de mesures de protection dans un document ne suffit pas : l’équipe doit vérifier quelles mesures s’appliquent effectivement au système qu’elle utilisera.

Enfin, ne choisissez pas sur la seule base des termes « ouvert », « géré » ou « sûr » sans préciser ce qu’ils signifient dans le cas considéré. Le choix est défendable lorsque l’équipe peut identifier le système, expliquer ses conditions d’utilisation, préciser ce qu’elle contrôle directement et étayer son évaluation des risques par des éléments adaptés. La même rigueur, dans une fiche consacrée aux organisations ou dans une future comparaison de fournisseurs, évite d’assimiler modèles, produits et politiques au seul motif qu’ils proviennent de la même entreprise.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.