Étude globale orientée activités réelles d’ingénierie embarquée. La taxonomie métier est maintenant séparée des familles de benchmarks internes ; les nouvelles activités utilisent provisoirement les preuves historiques les plus proches avant la prochaine phase de collecte.
Score propre à chaque configuration × tâche. Il mesure uniquement la rentabilité attendue d’obtenir un résultat acceptable. 50 = break-even avec l’humain · >50 = IA plus rentable · <50 = humain plus rentable · 0 = tâche non réalisable.
La fiabilité A–E, le wall-clock agent, la simplicité et l’autonomie restent affichés comme informations séparées et ne modifient plus le MetaScore.
Tous les filtres ci-dessus s’appliquent à ce tableau. Les estimations D/E restent visibles : elles permettent de comparer, tout en indiquant clairement leur faible fiabilité.
| # | Configuration | Disponibilité | Décision | MetaScore | P(succès) | Preuves | Couverture | API / tentative | Agent wall-clock | Humain actif IA | Coût / tentative | Coût IA / succès | Humain sans IA | Rentabilité vs humain |
|---|
Le grade affiché est le grade effectif pour T. Une preuve source A/B peut devenir D si elle est transférée d’une autre tâche, ou E si elle est transférée en plus vers un harness seulement compatible.
Ce sommaire répond à une autre question : « pour chaque tâche, quelles solutions IA sont économiquement intéressantes ? »
La sélection ci-dessous ignore volontairement la fiabilité des preuves et classe les solutions par coût attendu d’un résultat acceptable. Pour chaque tâche, on prend la meilleure configuration économique de chaque modèle, on retire toutes les solutions dont le coût attendu par succès est supérieur ou égal au coût humain sans IA, puis on affiche les modèles les plus rentables entre eux. La fiabilité reste affichée à titre informatif, mais n’intervient pas dans la sélection.
| Domaine | Tâche | Humain sans IA | Solutions IA les plus rentables | Meilleur coût IA / succès | MetaScore | Économie vs humain |
|---|
Les scaffolds et runners d’évaluation ont été retirés de cette matrice et des recommandations. Ils restent utilisés uniquement comme sources de preuve.
La taxonomie visible est désormais orientée métier d’ingénierie embarquée et cycle en V : exigences, architecture, développement MCU/MPU, drivers, debug/upstream, vérification, safety/cyber/ASPICE, GitLab CI/tooling, documentation, collaboration Jira/Confluence/SharePoint et formation continue. Les familles de benchmarks génériques restent une couche interne. À ce stade, les nouvelles activités héritent provisoirement des familles de preuves les plus proches ; une collecte spécifique sera réalisée dans l’étape suivante.
Chaque activité porte désormais des métadonnées explicites : secteurs Automobile / IoT industriel / Commun, plateformes et outils réellement utilisés, formats/artefacts, actions attendues de la solution IA et sensibilité typique des données. Elles serviront à la prochaine phase pour vérifier qu’une solution recommandée sait réellement travailler avec l’environnement cible : GitLab/Jira/Confluence/SharePoint, DOCX/XLSX/PPTX/PDF, Reqtify, OpenFastTrace/Sphinx, formats texte-as-code, HIL et outillage embarqué.
La rentabilité ne suffira pas à rendre une solution admissible. Les tâches peuvent manipuler des données publiques, internes/confidentielles ou client/sensibles. La future méta-analyse devra donc distinguer les solutions SaaS privées des solutions autorisées, souveraines ou déployées dans un parcours de données maîtrisé, et permettre un mix de solutions selon la sensibilité.
« J’ai besoin de faire T : quelle configuration modèle × harness × paramètres dois-je utiliser, et lesquelles puis-je écarter ? » Le grand tableau principal fusionne toutes les solutions de l’étude et applique les filtres actifs. Le sommaire économique transversal, plus bas, parcourt toutes les tâches indépendamment de ces filtres.
La disponibilité est un attribut, pas un filtre : Scaleway Serverless, Scaleway Dedicated, Scaleway déprécié mais encore actif, ou hors Scaleway / benchmark public. Les modèles dont l’EOL est déjà passé sont retirés.
Lorsqu’une configuration n’a pas de benchmark direct pour T, l’étude produit une estimation. Priorité : 1) transfert de la même configuration depuis une tâche voisine ; 2) transfert du même modèle depuis un autre harness ; 3) prior empirique de la classe de tâche. Ces niveaux sont respectivement plafonnés à D ou E et conduisent généralement à « à benchmarker ».
La qualité d’une source est évaluée relativement à ce qu’on lui demande de prouver. Un benchmark primaire A sur le bon modèle mais sur une tâche différente ne reste pas A pour T : le transfert le dégrade. De même, une compatibilité documentée avec un harness sans benchmark cross-harness donne au mieux une estimation E.
Un score de benchmark n’est jamais injecté mécaniquement dans une tâche simplement parce qu’il concerne « le code ». Chaque famille reçoit une pertinence pour T. En dessous de 55 %, le benchmark est exclu du calcul direct de Performance : il reste visible comme contexte, et ne peut influencer qu’une estimation régressée vers le prior de tâche. Exemple : LiveCodeBench/HumanEval renseignent la capacité de génération de code isolé, mais ne mesurent pas directement la création agentique d’une app depuis une spécification.
Lorsque les benchmarks réellement pertinents manquent, l’étude recherche des traces plus faibles mais plus proches du travail réel : retours Reddit, expériences de développeurs, issues, petits bake-offs, benchmarks communautaires. Ces sources sont converties en indices interprétés, jamais présentées comme des mesures fortes, et reçoivent un grade D/E. Des signaux contradictoires sont conservés ensemble afin que l’estimation reflète leur dispersion au lieu de sélectionner seulement les témoignages favorables.
Le tableau de décision ne propose que des surfaces réellement utilisables : harness/CLI/IDE installable, bridge ACP exploitable, runtime ou API/service fournisseur. Les scaffolds de model cards, Terminus, OSWorld runners et autres environnements de benchmark ne sont jamais proposés comme configuration à choisir. Ils peuvent néanmoins apporter des preuves sur le modèle. Leurs résultats continuent néanmoins d’alimenter l’estimation de P(success) d’un même modèle lorsqu’ils sont sémantiquement pertinents pour T.
Les observations restent séparées et dépliables. L’agrégation utilise pertinence pour T × qualité de preuve. Les scores hétérogènes sont normalisés relativement au meilleur résultat présent sur le même benchmark/version avant agrégation.
Sans preuve directe, le score est obtenu à partir des résultats normalisés disponibles pour la même configuration ou le même modèle, avec une pénalité de transfert. Sans aucune mesure du modèle, un prior empirique de la classe de tâche est utilisé. Ce chiffre sert à comparer et à prioriser les benchmarks à réaliser ; il ne doit pas être interprété comme une mesure.
Les tarifs Scaleway connus sont combinés à un profil de tokens/audio propre à T. Pour les autres fournisseurs ou les déploiements dédiés sans tarif exploitable, le rapport utilise un coût API médian observé pour la tâche, puis le classe E. Le temps humain actif et le temps humain sans IA restent des proxys D valorisés à 50 €/h.
Si le coût attendu par succès dépasse le coût humain sans IA, la configuration est écartée lorsque les preuves sont suffisamment solides. Avec une estimation D/E, elle n’est écartée que si l’écart est important ; sinon elle reste « à benchmarker ».
La dominance est désormais économique : pour une même tâche, une configuration est dominée lorsqu’une autre produit un résultat acceptable pour un coût attendu par succès nettement inférieur. Une marge de 10 % est utilisée pour les mesures directes et de 20 % pour les estimations afin de ne pas surinterpréter de petits écarts numériques.
Le MetaScore n’est plus une moyenne pondérée de critères. Il est une transformation directe du coût attendu par résultat acceptable relativement au coût humain de la même tâche. La fiabilité des preuves, le temps wall-clock de l’agent, l’autonomie et la simplicité opérationnelle sont conservés comme informations séparées.
Le sommaire par tâche a une philosophie différente : il ignore volontairement la fiabilité des preuves dans la sélection. Il prend, pour chaque modèle, sa configuration au plus faible coût attendu par succès, exclut toute solution dont ce coût est supérieur ou égal au coût humain sans IA, puis affiche les cinq modèles les plus rentables. Le grade reste affiché uniquement comme information de prudence.
Le MetaScore répond à une question unique : « pour cette tâche T, cette configuration IA est-elle économiquement plus intéressante que réaliser la tâche sans IA, et de combien ? » Il est calculé séparément pour chaque couple configuration × type de tâche. Une même configuration possède donc autant de MetaScores qu’il existe de tâches évaluées.
Le MetaScore ne cherche pas à mesurer la sophistication d’un modèle, sa qualité générale, la simplicité de son installation ou notre confiance dans les sources. Il cherche uniquement à représenter la rentabilité attendue en usage quotidien.
P(success) est la probabilité estimée qu’une tentative produise un résultat acceptable pour T, c’est-à-dire qu’elle satisfasse la Definition of Done de la tâche. Au niveau d’une tentative, le résultat est considéré comme binaire : succès ou échec.
La notion de « qualité esthétique » d’un résultat déjà acceptable n’ajoute pas de points au MetaScore. Un résultat qui remplit la tâche est un succès ; un résultat qui nécessite de refaire réellement la tâche est un échec. Les benchmarks, retours terrain et estimations servent à estimer cette probabilité. Leur fiabilité A–E est affichée séparément.
Si P(success) = 0, la configuration est incapable de réaliser T : son MetaScore vaut 0.
CAPI représente le coût variable de l’IA pour une tentative : tokens d’entrée/sortie, audio ou autre consommation facturée. Lorsque le fournisseur publie un tarif et que le profil de consommation de T est connu ou estimé, ce coût est reconstruit. Sinon un proxy issu des données disponibles est utilisé et reçoit un grade de confiance plus faible.
Thumain,IA est le temps de travail humain réellement consommé pendant l’usage quotidien de l’agent. Il inclut notamment : formulation et ajustement du prompt, guidage, réponses aux questions de l’agent, surveillance active lorsqu’elle est nécessaire, lecture/revue du résultat, corrections et relances normales.
Il n’inclut pas le temps initial d’installation ou de configuration de l’outil, ni le temps pendant lequel l’agent travaille seul sans mobiliser l’utilisateur. Ainsi, un agent lent mais autonome peut être économiquement meilleur qu’un agent rapide nécessitant de nombreuses interventions.
Le taux de référence actuel est Rhumain = 50 €/h, correspondant à 400 € par journée de 8 heures. Cette hypothèse sert aussi bien au temps humain passé à piloter l’IA qu’au temps nécessaire pour effectuer la tâche entièrement sans IA.
Ctentative = CAPI + (Thumain,IA / 60) × Rhumain
Cette variable matérialise un principe central de l’étude : un modèle très bon marché qui monopolise un ingénieur peut être plus coûteux qu’un modèle API plus cher mais réellement autonome.
Csuccès IA = Ctentative / P(success)
Exemple : une tentative coûte 10 € et réussit 80 % du temps. Le coût attendu d’un résultat acceptable est 10 / 0,8 = 12,50 €. Les échecs sont donc automatiquement pénalisés sans ajouter un critère « performance » séparé.
Chumain = (Thumain,sans IA / 60) × Rhumain
Thumain,sans IA représente le temps estimé nécessaire à un professionnel pour accomplir une tâche comparable sans agent IA. C’est le point de référence économique commun à toutes les configurations évaluées pour T.
MetaScore = 100 × Chumain / (Chumain + Csuccès IA)
Cette transformation borne naturellement la rentabilité entre 0 et 100 et donne un seuil immédiatement interprétable :
Le tableau affiche également Facteur de rentabilité = Chumain / Csuccès IA. Un facteur 4× signifie qu’obtenir un résultat acceptable avec l’IA coûte quatre fois moins cher qu’en humain seul. Ce facteur et le MetaScore portent la même information économique sous deux formes différentes.
Le MetaScore est une estimation de valeur économique. Le grade A–E est une estimation de confiance. Ces deux dimensions doivent être lues ensemble mais ne doivent pas être multipliées ni moyennées. Exemple : MetaScore 85 · confiance B signifie « rentable et assez bien étayé » ; MetaScore 85 · confiance E signifie « potentiellement rentable, priorité élevée pour un benchmark interne ».
La méthode est conçue pour accepter ultérieurement des résultats internes : nombre de succès/échecs, coût API réel, temps humain actif réellement mesuré et éventuellement temps wall-clock. Ces observations pourront améliorer P(success), CAPI et Thumain,IA sans changer la définition du MetaScore.