Skip to main content

Ce qui compte comme preuve d'un AI component

Remarque : Ce document est une traduction automatique de la version originale anglaise.

Ce qui compte comme preuve d'un AI component

Quand DecAIHub évalue si un projet possède un composant IA fonctionnel, il cherche des artefacts vérifiables — pas des textes marketing, pas des promesses, pas des associations de marques. Cette page liste les types de preuves qui renforcent l'axe AI reality du score DecAI Fit, classés du plus fort au plus faible.

En bref : une preuve d'IA, ce sont des artefacts que vous pouvez inspecter, tester ou vérifier indépendamment — code, documentation, métriques avec méthodologie, démos fonctionnelles et évaluations tierces.

Preuves Tier-1 (les plus fortes)

Les sources Tier-1 sont des artefacts publiés ou contrôlés par le projet lui-même. Pour l'axe AI reality, les preuves Tier-1 les plus fortes incluent :

  • Dépôt public avec du code AI/ML — scripts d'entraînement de modèles, logique d'inférence, pipelines de données, étapes de prétraitement. Un dépôt avec des commits, des releases et des tests est bien plus fort qu'un dépôt vide avec un README.
  • Documentation technique — descriptions de l'architecture du modèle, formats d'entrée/sortie, versions du modèle et historique des mises à jour. Cela répond à « quel modèle, comment il fonctionne, et quelle version tourne ».
  • Métriques de qualité avec méthodologie — benchmarks ou résultats d'évaluation publiés qui précisent ce qui a été mesuré, sur quelles données, quand et avec quelle version du modèle. Des métriques sans ce contexte ne sont pas des preuves.
  • Démos ou points de terminaison fonctionnels — une interface, une API ou un bac à sable publiquement accessibles où le composant IA peut être testé. Une démo qui traite de vraies entrées et retourne des sorties pilotées par l'IA est une preuve directe.
  • Rapports d'audit ou évaluations tierces — évaluations indépendantes de la qualité, de l'équité, de la sécurité ou de la performance du modèle par une entité reconnue.

Schémas qui renforcent les preuves Tier-1

Tous les artefacts Tier-1 ne sont pas également convaincants. Plusieurs schémas observables rendent les preuves plus crédibles :

  • Profondeur de l'historique des commits. Un dépôt avec des mois ou des années de commits incrémentaux, de pull requests, de revues de code et de releases versionnées démontre un effort d'ingénierie soutenu. Un unique téléversement en masse pèse bien moins.
  • Couverture de tests et pipelines CI. Des tests automatisés pour l'inférence du modèle, la validation des données et les points d'intégration indiquent un système de qualité production plutôt qu'une preuve de concept.
  • Modèles versionnés et changelogs. Quand la documentation suit quelle version du modèle est déployée, ce qui a changé entre les versions et pourquoi, cela signale un système vivant avec un cycle de développement actif.
  • Sorties reproductibles. Si une démo ou une API retourne des résultats cohérents et explicables pour les mêmes entrées d'une session à l'autre, c'est plus fort qu'une vitrine ponctuelle.
  • Séparation de la logique IA et du code générique. Une base de code où les modules AI/ML sont clairement identifiables — distincts de l'échafaudage frontend, des scripts de déploiement ou des contrats de token — facilite la vérification de ce que fait réellement le composant IA.

Preuves Tier-2 (du contexte, pas des preuves)

Les sources Tier-2 fournissent du contexte mais ne prouvent pas à elles seules un composant IA fonctionnel :

  • Interviews ou AMA où l'équipe décrit l'approche IA, l'architecture ou le processus d'entraînement.
  • Descriptions d'agrégateurs (CoinGecko, DeFiLlama, etc.) mentionnant des capacités IA.
  • Annonces de partenariats avec des fournisseurs d'IA ou des laboratoires de recherche.

Une preuve Tier-2 peut soutenir un constat Tier-1 mais ne peut pas le remplacer. Un partenariat avec une entreprise d'IA ne prouve pas que le projet dispose de sa propre IA fonctionnelle.

Quand les preuves Tier-2 comptent

Les sources Tier-2 deviennent pertinentes quand elles corroborent des artefacts Tier-1 ou comblent des lacunes que le Tier-1 seul laisse ambiguës :

  • Une interview technique où l'équipe détaille l'architecture décrite dans sa documentation ajoute de la crédibilité aux docs Tier-1.
  • Une fiche d'agrégateur qui correspond aux capacités décrites dans le whitepaper du projet signale de la cohérence.
  • Une conférence avec démo en direct qui reflète le comportement de l'API publique du projet renforce l'idée que la démo n'est pas scriptée.

Sans artefacts Tier-1 sous-jacents, cependant, même des sources Tier-2 convaincantes restent du contexte — précieux pour la compréhension, insuffisant pour la vérification.

Ce qui ne compte pas

Certains artefacts ressemblent à des preuves mais ne démontrent pas un composant IA fonctionnel. Les faux signaux courants incluent les textes marketing, les dépôts vides, les métriques sans méthodologie et les wrappers d'API sans logique propriétaire. Pour une liste détaillée, voir Ce qui ne compte pas comme preuve d'IA.

Comment DecAIHub consigne les preuves d'IA : les flags AI_0 à AI_4

L'axe AI reality utilise cinq flags binaires pour saisir quelles preuves ont été trouvées :

Flag Ce qu'il vérifie Valeur
AI_0 Existe-t-il au moins une déclaration Tier-1 d'intention IA (roadmap, communication officielle) 1 / 0
AI_1 Existe-t-il une description de ce que fait l'IA 1 / 0
AI_2 Existe-t-il des démos ou des exemples fonctionnels 1 / 0
AI_3 Existe-t-il des métriques de qualité avec contexte (quoi, sur quelles données, quand) 1 / 0
AI_4 Existe-t-il une description technique, une architecture ou des versions de modèle 1 / 0

Plus il y a de flags à 1, plus le ai_score est élevé, et meilleur est le DecAI Fit du projet. Si aucun flag n'est activé, ai_score = 0 et le DecAI Fit ne peut pas dépasser 0.

Comment les combinaisons de flags se traduisent en confiance

Les flags individuels répondent à des questions étroites, mais leur combinaison dresse un tableau plus complet :

Flags activés Interprétation typique
AI_0 seul Intention déclarée ; aucune IA fonctionnelle vérifiée pour l'instant
AI_0 + AI_1 IA décrite en mots ; pas de démo, pas de métriques, pas d'architecture
AI_0 + AI_1 + AI_2 Une démo fonctionnelle existe ; toujours pas de métriques ni de profondeur technique
AI_0 + AI_1 + AI_2 + AI_4 Démo et architecture présentes ; mesure de qualité manquante
Les cinq (AI_0 à AI_4) Profil de preuves le plus fort : intention, description, démo, métriques et architecture

Un projet n'a pas besoin de satisfaire les cinq flags pour recevoir un ai_score non nul. Même AI_0 seul (intention avec une source Tier-1) donne ai_score = 1. Cependant, les flags supérieurs contribuent à un plafond plus élevé pour le DecAI Fit.

Pourquoi la méthodologie compte pour les métriques

Un chiffre isolé — « 95 % de précision », « faible latence », « état de l'art » — n'est pas une preuve sans contexte. DecAIHub ne considère les métriques comme significatives que lorsqu'elles répondent à quatre questions : quoi a été mesuré (précision, F1, latence, perplexité), sur quelles données (benchmark public, jeu de test propriétaire, trafic de production), quand (date de l'évaluation), et quelle version du modèle a produit le résultat. Sans cela, une métrique est une affirmation, pas une preuve.

Le test des quatre questions

Pour évaluer toute métrique publiée, appliquez cette liste de contrôle :

  1. Quoi — La métrique est-elle nommée et définie ? « Précision » est ambigu ; « précision de classification top-1 » est spécifique.
  2. Sur quelles données — Le jeu de données d'évaluation est-il identifié ? Un benchmark public permet la reproduction indépendante ; un jeu de test propriétaire non, mais le nommer vaut mieux que le silence.
  3. Quand — Y a-t-il une date ou un tag de release ? Les modèles changent avec le temps ; une métrique sans horodatage peut ne pas refléter le système actuel.
  4. Quelle version — La version du modèle ou du système est-elle indiquée ? Si un projet a livré plusieurs itérations de modèle, la métrique doit être rattachée à une itération précise.

Si l'une de ces quatre réponses manque, la métrique passe de « preuve » à « affirmation » dans l'évaluation de DecAIHub. Elle peut toujours figurer dans la fiche projet comme affirmation notée, mais elle ne contribuera pas à mettre le flag AI_3 à 1.

Comment utiliser cette liste de contrôle

En lisant une fiche projet, vérifiez si la table Evidence référence des artefacts de la liste Tier-1 ci-dessus. Si la fiche affiche ai_score = 0 ou signale une préoccupation d'AI-washing, cela signifie que ces artefacts n'ont pas été trouvés à la date de vérification — ce n'est pas une accusation contre le projet.

Quand de nouveaux artefacts Tier-1 apparaissent, la fiche est mise à jour et le score peut changer.

Étapes pratiques pour les lecteurs

  • Commencez par la table Evidence. Cherchez des liens vers des dépôts, de la documentation ou des démos. Si la table Evidence est vide ou ne référence que des sources Tier-2/3, l'affirmation d'AI reality n'est pas vérifiée.
  • Cliquez jusqu'aux artefacts. Un lien vers un dépôt ne vaut que par ce qu'il contient. Ouvrez-le et cherchez du code AI/ML, pas seulement un README ou des scripts de déploiement.
  • Vérifiez la date de vérification. Une preuve est un instantané. Une fiche vérifiée il y a six mois peut ne pas refléter l'état actuel du projet, raison pour laquelle DecAIHub applique une pénalité d'obsolescence après 550 jours.
  • Recoupez avec la liste des anti-schémas. Si vous repérez des schémas de Ce qui ne compte pas comme preuve d'IA, pondérez les preuves en conséquence.

Ce que cette liste de contrôle seule ne prouve pas

  • Satisfaire tous les critères de preuve ne prouve pas que l'IA est de haute qualité ou utile aux utilisateurs finaux. Cela prouve que des artefacts existent et peuvent être inspectés.
  • Une preuve Tier-1 émanant du projet lui-même ne prouve pas l'indépendance. Les données auto-déclarées devraient idéalement être corroborées par une évaluation tierce.
  • Un dossier de preuves complet ne prouve pas que le token est nécessaire. L'AI reality est un axe du DecAI Fit ; la nécessité du token en est un autre.

Questions fréquentes

Qu'est-ce qui constitue la preuve la plus complète d'IA dans un projet crypto ?

Un dépôt public contenant du code AI/ML avec un historique de commits significatif, combiné à des métriques de qualité publiées incluant une méthodologie complète (ce qui a été mesuré, sur quelles données, quand et avec quelle version du modèle). Quand ces deux éléments existent et sont appuyés par une démo fonctionnelle ou un point de terminaison API, le profil de preuves est à son maximum. Aucun artefact isolé n'est définitif en soi — c'est la combinaison de code, de métriques et de sorties testables qui distingue une IA vérifiée d'affirmations non vérifiées.

Un projet peut-il avoir une vraie IA sans code open source ?

Oui. Le code open source est la forme de preuve la plus transparente, mais ce n'est pas la seule. Un projet peut démontrer son IA par une documentation technique détaillée, des benchmarks publiés avec méthodologie, des API fonctionnelles retournant des sorties vérifiables pilotées par l'IA, ou des évaluations tierces indépendantes. Cependant, sans au moins un artefact inspectable — code, démo ou évaluation — il n'y a rien que DecAIHub (ou quiconque) puisse vérifier. Plus un projet est fermé, plus il dépend de la corroboration Tier-2 (interviews, données d'agrégateurs, démonstrations en conférence) pour bâtir sa crédibilité.

Une démo fonctionnelle prouve-t-elle que l'IA est réelle ?

Une démo fonctionnelle est une preuve forte, mais pas une preuve concluante en soi. Un frontend bien conçu peut simuler un comportement de type IA avec des réponses codées en dur, des résultats précalculés ou des appels cachés à une API tierce. DecAIHub traite les démos comme des preuves plus fortes quand elles s'accompagnent d'une documentation d'API, d'identifiants de version de modèle ou de sorties reproductibles pour différentes entrées. Une démo qui accepte des entrées utilisateur arbitraires et retourne des sorties variées et contextuellement appropriées est plus convaincante qu'une vitrine guidée aux exemples prédéterminés.

Quelle est la preuve minimale pour un ai_score non nul ?

Le minimum est une déclaration Tier-1 d'intention IA — une entrée de roadmap, un billet de blog officiel ou une page de documentation qui énonce explicitement des plans liés à l'IA. Cela met le flag AI_0 à 1 et produit ai_score = 1. Bien que ce soit le plus bas score non nul possible, il distingue les projets qui se sont officiellement engagés dans une direction IA de ceux qui n'ont jamais mentionné l'IA. Pour atteindre des scores plus élevés, le projet doit fournir des artefacts supplémentaires : descriptions du composant IA (AI_1), démos (AI_2), métriques avec méthodologie (AI_3) et détails d'architecture technique (AI_4).

Références externes

  • CommonMark specification — le standard de balisage utilisé sur toutes les pages du wiki DecAIHub, y compris les fiches projet et les explainers.
  • Model Cards for Model Reporting (Mitchell et al., 2019) — un cadre fondateur pour documenter la performance, l'usage prévu et les limites des modèles d'IA ; étroitement aligné avec les principes de transparence derrière les critères de preuve de DecAIHub.
  • NIST AI Risk Management Framework — un cadre gouvernemental américain pour identifier et gérer les risques de l'IA, incluant des recommandations sur la documentation, les tests et la méthodologie d'évaluation.

Voir aussi

No comments to display

Back to top