Résumé

  • Lynx a annoncé le 9 septembre l'AI Deployment Gap Initiative avec sept autres participants fondateurs et des projets de ressources techniques communes.
  • L'adhésion est sans frais ni obligations formelles. Elle ne démontre pas qu'un produit ou un déploiement a réussi une évaluation de sûreté.

Une architecture peut être portable sans que les preuves qui la justifient le soient. Lorsqu'un intégrateur remplace un composant, retrouver les hypothèses derrière les anciens essais peut coûter plus cher que récupérer le schéma du système.

Voilà une mesure possible de l'intérêt commercial de l'initiative annoncée par Lynx le 9 septembre. Critical Software, Edera, Metavonics, OmniTrust, PACE, RunSafe Security et TASKING en sont les sept autres participants fondateurs. Ils prévoient de travailler sur des guides, cadres de préparation au déploiement, architectures de référence, livres blancs, plans de mise en œuvre et retours d'exploitation pour l'IA physique. L'annonce ne présente pas cet ensemble comme déjà terminé et validé indépendamment.

L'adhésion ne vaut pas qualification

Le site de l'initiative décrit une démarche indépendante des fournisseurs, réunie à l'invitation de Lynx. La participation commence par une conversation, sans frais ni obligations formelles. Les organisations peuvent choisir de contribuer à des activités pédagogiques communes.

Cette ouverture facilite la rencontre d'expertises différentes. Elle ne désigne toutefois pas automatiquement un responsable de maintenance pour chaque ressource, ni une procédure d'approbation des produits des membres. Une liste de soutiens ne dit pas quelle configuration a été essayée, dans quelles conditions et par qui. Les documents de lancement ne créent pas une nouvelle distinction de certification. L'absence d'obligations formelles concerne la participation, pas les responsabilités des entreprises envers leurs clients.

Le manifeste de quatre pages distingue les difficultés d'exécution, d'intégration, de gouvernance et de cycle de vie. Sa nuance importante est qu'une exécution prévisible peut entourer des résultats probabilistes : maîtriser les délais n'assure pas que chaque inférence est correcte. Il appelle aussi à la résilience lorsqu'un correctif de sécurité n'est pas encore disponible, non à l'abandon des correctifs.

Ce qu'un autre intégrateur doit pouvoir reprendre

Prenons le cas hypothétique d'un changement de module de calcul. Une référence utile aiderait à séparer les hypothèses encore valides, les limites propres à l'ancienne configuration et les conclusions nécessitant une nouvelle vérification. L'assemblage de logos sur un schéma ne fournit pas cette réponse.

Une configuration testée explicitement, des versions identifiables et un responsable de suivi faciliteraient l'évaluation et la réutilisation des travaux. Ce sont des critères d'analyse, pas un format ou un service que l'initiative aurait déjà annoncé. La publication commune et la reproduction d'un résultat par une autre équipe restent deux étapes distinctes.

Lynx n'est pas seulement un organisateur de discussions. Sa page commerciale LYNX MOSA.ic.AI présente une plateforme CPU/GPU autour de l'exécution contrôlée, de l'isolation et de la portabilité dans le temps. Faire reconnaître le problème d'ingénierie auquel répond son produit a un intérêt économique. Cela ne prouve pas une exclusivité de l'initiative ; les modalités de participation n'imposent pas l'achat de cette plateforme.

La neutralité annoncée se jugera mieux à la possibilité de comparer des solutions et de conserver des preuves utiles en changeant de fournisseur. Les documents examinés ne tranchent pas les licences des futurs livrables, les droits de décision, le financement de leur maintenance ou les dates de livraison. Un manque de précision publique ne démontre pas l'absence de ces arrangements.

Un vocabulaire partagé peut déjà réduire les malentendus. Réduire le coût de la confiance justifiée d'une version de système à la suivante serait un résultat plus ambitieux. Il reste à l'établir.