Méthode du diagnostic de livraison — v2025.2-1

Version du modèle : v2025.2-1 (millésime du rapport DORA 2025, v. 2025.2, et révision 1 des règles JDUCRAFT). Les changements sont listés dans CHANGELOG.md.

Ligne de millésime : aligné sur le rapport DORA 2025 (v. 2025.2), le DORA AI Capabilities Model (v. 2025.1) et « The ROI of AI-assisted Software Development » (v. 2026.1). Le 3 septembre 2026, DORA a annoncé qu'il ne mènerait pas de sondage annuel cette année et ne publierait pas de rapport 2026 ; les données 2025 restent la référence publiée.

1. Trois étiquettes de provenance

Chaque chiffre et chaque phrase du résultat porte l'une de ces trois étiquettes.

Étiquette	Ce qu'elle couvre
« Donnée DORA 2025 — fig. N, p. M »	Un fait publié par DORA : bandes et distributions des figures 11 à 15, distributions IA des figures 19, 20, 21, 23 et 26, parts et coordonnées des sept profils (p. 13, fig. 10 p. 19), étiquettes d'effet par niveau de capacité (AICM, fig. 3 à 17). Cité avec la figure et la page, jamais reproduit en image ni en prose.
« Lecture JDUCRAFT »	Un raisonnement JDUCRAFT appuyé sur des pages DORA : la contrainte probable, ses étiquettes de confiance, le verdict IA, les premiers gestes, les questions marquées JDUCRAFT. Ce n'est pas une donnée DORA.
« Estimation (seuils publiés sur la page Méthode) »	Une conversion chiffrée choisie par JDUCRAFT : percentile de rang moyen, seuils 40/60, seuils des échelles de Likert, placement d'un ou deux items sur l'axe à cinq niveaux de l'AICM, règle de concordance des profils, lecture des figures de l'AICM.

Pages citées : ce sont les numéros de page du fichier PDF (première page du PDF = page 1). Pour le rapport DORA 2025 et le rapport ROI, ils coïncident avec les folios imprimés. Pour l'AICM, le folio imprimé vaut un de moins que la page citée : la figure 27, citée p. 78, porte le folio 77.

Ce que le rapport ne permet pas d'affirmer et que l'outil n'affirme jamais : un « score DORA » composite ou un palier (le rapport 2025 n'en publie aucun), une distance numérique à un profil, « vous êtes le profil X », une trajectoire entre profils, une recommandation par profil attribuée à DORA, une relation de cause à effet (données déclaratives et transversales ; les métriques disent ce qui se passe, pas pourquoi, p. 14).

2. Table de provenance

Élément	Source	Licence
Énoncés anglais des cinq items de livraison (lead_time, deployment_frequency, recovery_time, change_failure_rate, rework_rate) et des 20 items de profil (module P)	dora.dev, « Team profiles survey questions », capture du 2026-11-08	CC BY 4.0
wait_dependency, ai_agent_mode, ai_tasks (adapté)	dora.dev, « DORA Research: 2025 – Survey Questions », capture du 2026-11-08	CC BY 4.0
changes_per_deployment, user_understanding, platform_feedback (adapté), ai_reliance, ai_trust, ai_reflexive, items du module C (stance_clarity, data_access, ai_internal_data, commit_frequency, rollback_reliance, task_duration, user_feedback)	dora.dev, « AI Capabilities Model – Survey Questions », capture du 2026-11-08	CC BY 4.0
Énoncés français de tous les items	Traduction JDUCRAFT	CC BY 4.0 (adaptation)
wait_where, vsm_drawn, module F (first_pass_acceptance, flow_efficiency, baseline)	JDUCRAFT, chaque item cite les pages DORA qui l'inspirent	CC BY 4.0
Distributions des figures 11 à 15 (32 valeurs), figures 19, 20, 21, 23, 26, parts des profils, coordonnées de la figure 10	Rapport DORA 2025, v. 2025.2, figure et page citées	faits cités (rapport sous CC BY-NC-SA 4.0, non reproduit)
Étiquettes d'effet par niveau de capacité	DORA AI Capabilities Model, v. 2025.1, figures 3 à 17 ; lecture des figures par JDUCRAFT	faits cités (rapport sous CC BY-NC-SA 4.0, non reproduit)
Noms des sept profils	Rapport DORA 2025, cités comme référence	—
Descriptions des profils, règles, seuils, étiquettes de confiance, verdict IA, premiers gestes	JDUCRAFT	CC BY 4.0

Adaptations déclarées (champ adaptationNote de src/content/items.ts) :

• platform_feedback : DORA demande d'abord si une plateforme a été utilisée dans les trois derniers mois ; ce filtre est replié dans l'option « Sans objet ». La ligne d'aide joint l'amorce de la grille AICM à la définition de la plateforme, qui vient de la page « DORA Research: 2025 – Survey Questions » et non de la page AICM.
• ai_tasks : DORA demande, pour 27 tâches, le degré d'appui sur l'IA sur cinq niveaux ; neuf tâches logicielles sont gardées avec les libellés DORA, en choix multiple à l'échelle de l'équipe.

Ajouts déclarés sans adaptation de l'énoncé (champ note) : la ligne d'aide des cinq items de livraison (« Comptez du commit à la production… », « Plusieurs services ? … », « Saisissez une valeur de 0 à 100… ») est un ajout JDUCRAFT ; l'énoncé et les options restent ceux de DORA. Pour rollback_reliance, l'option anglaise porte déjà toute la description de DORA, ponctuation comprise ; l'option française la traduit en entier, sans ligne d'aide séparée. Le test src/content/items.test.ts exige cette déclaration pour toute ligne d'aide d'un item DORA absente des captures.

Le test src/content/items.test.ts vérifie que l'énoncé et chaque option anglaise des items DORA figurent mot pour mot dans les captures de docs/sources/.

3. Repères de livraison (bloc A) — « Donnée DORA »

Pour chaque métrique répondue, la tranche est placée dans la distribution publiée (fig. 11 à 15, pp. 20–21). Trois nombres, calculés à partir de la colonne cumulée du rapport pour éviter la dérive des arrondis :

• même tranche = « % at level » de la tranche ;
• mieux = « Top % » de la tranche immédiatement meilleure ;
• moins bien = 100 − « Top % » de la tranche choisie.

La phrase dit toujours le sens : un délai plus court, une fréquence plus élevée, un rétablissement plus rapide, un taux plus bas sont « mieux ». Jamais « Top x % ».

Taux d'échec et taux de reprise se saisissent en entiers de 0 à 100 ; la valeur est rangée dans la tranche du rapport, bornes supérieures incluses : 2 % est dans 0–2 %, 16 % dans 8–16 % (17 % dans 16–32 %), 64 % dans 32–64 %. Les étiquettes des figures 14 et 15 se chevauchent aux bornes (« 8–16 % », « 16–32 % ») ; la convention JDUCRAFT range la borne dans la tranche la plus basse. Une valeur non entière est lue comme sans réponse, par le moteur comme par le code de résultat : un aller-retour par le code ne change donc jamais de tranche.

Niveaux (Estimation). Percentile de rang moyen d'une tranche = moins bien + même tranche ÷ 2. Débit = moyenne des percentiles répondus parmi délai, fréquence, rétablissement ; stabilité = moyenne parmi taux d'échec et taux de reprise. Bas si p < 40, Moyen si 40 ≤ p ≤ 60, Élevé si p > 60 ; le niveau d'instabilité est la lecture inverse de la stabilité. « Je ne sais pas » est exclu ; un facteur sans réponse est « non mesuré ».

Contrôles (tests src/content/benchmarks.test.ts) : le répondant médian 2025 (1 jour–1 semaine, hebdomadaire–mensuel, moins d'un jour, 8–16 %, 8–16 %) obtient p = 53,4 en débit et 55,6 en stabilité, donc Moyen sur les deux. Sous indépendance des items, l'échantillon 2025 se répartit en débit Bas 26 % / Moyen 43 % / Élevé 31 %, en stabilité Bas 30 % / Moyen 39 % / Élevé 31 %. C'est une estimation : le rapport ne publie pas la distribution jointe.

Dénominateur : 4 867 répondants, sondage du 13 juin au 21 juillet 2025 ; le n de chaque figure n'est pas publié.

4. Position IA (bloc C) — « Donnée DORA »

Pour ai_reliance (fig. 20, p. 27), ai_trust (fig. 26, p. 31), ai_reflexive (fig. 19, p. 26) et ai_agent_mode (fig. 23, p. 29), la page donne la part des répondants 2025 qui ont répondu la même chose ou plus, avec son dénominateur (utilisateurs de l'IA ou ensemble des répondants). ai_tasks est comparé aux parts de la figure 21 (p. 27), avec ses deux dénominateurs. Aucun score composite d'adoption. Une lecture en trois niveaux (moyenne des positions 1–5 : faible < 2,5, modérée 2,5–3,5, forte > 3,5) sert seulement à formuler la section capacités et le repère « taxe de vérification » (Lecture JDUCRAFT).

5. Contrainte probable — « Lecture JDUCRAFT »

5.1 Familles

id	Famille	Réponses à wait_where
R	la revue de code	revue de code
T	les tests et la recette	tests ou QA
E	les environnements, l'infrastructure et les données	attente d'environnement
G	les validations avant mise en production	validation de mise en production (release) ; revue sécurité et conformité (security), gardée comme sous-file dans le texte
P	les décisions produit	décisions produit
N	aucune file détectée	rien n'attend plus de quelques heures

5.2 Table des règles

Tranches de délai, fréquence et rétablissement : 1 (la pire) à 6 (la meilleure), regroupées en lent (1 à 3 : une semaine ou plus), moyen (4) et rapide (5 et 6). Les taux sont « instables » à partir de la tranche 16–32 % (tranche ≤ 3). « Je ne sais pas » ne donne aucun point ; « Sans objet » non plus, sauf pour platform_feedback, où il signifie « pas de plateforme interne » et a sa propre règle. La table est la constante rules de src/engine/rules.ts ; les poids sont la constante WEIGHTS.

Deux règles sont génériques (generic: true) : elles disent qu'une file existe, pas laquelle. wait_dependency demande si l'on attend une personne ou une équipe, sans distinguer revue, tests, environnements ou validations ; flow_efficiency dit qu'un changement attend, pas où. Elles pèsent dans le total de la famille déclarée (0,5 point), jamais dans la corroboration.

Règle	Items lus	Condition	Points	Ancrage
declared_wait	wait_where	une famille est nommée	+3,25 à cette famille (« rien n'attend » : +3,25 N)	AICM p. 77
handoff_dependency (générique)	wait_dependency	« Souvent » ou « En permanence »	+0,5 au total de la famille déclarée, hors corroboration ; −1 N si « rien n'attend » ; signal sans point si non déclarée	AICM p. 77
batch_11_50	changes_per_deployment	11 à 50 changements	+1,2 G, +0,75 R, +0,7 T	AICM p. 47 ; rapport p. 57
batch_over_50	changes_per_deployment	plus de 50	+2,05 G, +0,75 R, +0,7 T	AICM p. 47 ; rapport p. 57
single_change_long_lead_time	changes_per_deployment, lead_time	un seul changement et délai lent	+1 R, +0,5 T	AICM p. 47 ; rapport p. 22
single_change	changes_per_deployment	un seul changement, délai non lent	−1 G, +0,5 N	AICM p. 47
long_lead_time	lead_time	délai lent (une semaine ou plus)	+1,5 R, +0,7 T, +0,55 E, +0,45 G	rapport pp. 22, 81
lead_time_slower_than_deploys	lead_time, deployment_frequency	le groupe du délai est plus lent que celui de la fréquence (lent contre moyen ou rapide, moyen contre rapide) : les changements attendent plus longtemps que l'intervalle entre deux déploiements	+1,5 R, +0,5 T	rapport pp. 13, 22, 81
short_lead_time_rare_deploys	lead_time, deployment_frequency	délai de moins d'une semaine et déploiements au plus hebdomadaires–mensuels	+1,2 G, +0,8 E	rapport p. 13 ; AICM p. 78, fig. 27
long_lead_time_rare_deploys	lead_time, deployment_frequency	délai lent et déploiements rares	+1,2 G	rapport p. 13 ; AICM p. 78, fig. 27
fast_flow	lead_time, deployment_frequency	délai de moins d'un jour et déploiements au moins quotidiens	+1 N ; −1 R, T, E, G (P intact : une file amont n'est pas réfutée par une livraison rapide)	rapport pp. 13, 39
high_change_failure_rate	change_failure_rate	au-delà de 16 %	+1,3 T, +0,5 R	ROI p. 9 ; rapport p. 57 ; AICM p. 39
high_rework_rate	rework_rate	au-delà de 16 %	+1,3 T	ROI p. 9 ; rapport p. 40
slow_recovery_days	recovery_time	1 jour à 1 semaine	+1,3 E, +0,45 G	AICM pp. 38, 80
slow_recovery_weeks	recovery_time	une semaine ou plus	+2,05 E, +0,45 G	AICM pp. 38, 80, 81
weak_user_understanding	user_understanding	1 à 3 sur 7	+2,2 P	AICM p. 55, fig. 16
unsure_user_understanding	user_understanding	4 sur 7	+1 P ; sous le seuil de 2, ne corrobore jamais seul : il faut un second signal P (long_tasks)	AICM p. 55, fig. 16
weak_platform	platform_feedback	« Pas du tout » ou « Légèrement »	+1,55 E	AICM pp. 61, 80
no_platform	platform_feedback	« Sans objet » (pas de plateforme interne)	+1,3 E	AICM pp. 61, 80
low_first_pass_acceptance (module F)	first_pass_acceptance	5–6 sur 10 ou moins	+1 R, +1 T	AICM p. 77
mostly_waiting (module F, générique)	flow_efficiency	surtout en attente	+0,5 au total de la famille déclarée, hors corroboration ; +0,5 R, +0,5 G si aucune	AICM p. 78
mostly_active (module F)	flow_efficiency	surtout travaillé	+1 N	AICM p. 78
long_tasks (module C)	task_duration	une semaine ou plus	+1 P	AICM p. 49
small_tasks_long_path (module C)	task_duration, lead_time	tâches de moins d'un jour et délai lent	+1 R, +1 G	AICM p. 49 ; rapport p. 22

Les poids qui ne sont pas des multiples de 0,25 (0,7, 0,55, 0,45, 1,2, 1,3, 1,55, 2,05, 2,2) servent à éviter que deux familles tombent sur le même total par coïncidence ; aucun écart de 0,05 ne change le sens d'un verdict.

vsm_drawn modifie le texte, jamais les points : « oui, et mesuré » ajoute « — mesurée par votre équipe » à l'étiquette ; « non » ou « en partie » ajoute la phrase sur le premier jour de l'audit.

Repère « taxe de vérification » : affiché quand un taux d'instabilité dépasse 16 % et que ai_reliance vaut « A lot » ou plus (ROI pp. 9, 20, 33, 40). Il ne change aucun point.

5.3 Étiquettes de confiance et seuils

Total d'une famille = somme de ses points. Corroboration = points reçus des règles propres à une famille, hors declared_wait et hors règles génériques : une corroboration de 2 points demande donc toujours au moins une règle propre à la famille déclarée. Famille principale = total le plus élevé ; famille secondaire = la suivante si son total est positif et à 1 point ou moins.

Étiquette	Condition
Déclarée et corroborée	la famille déclarée est principale et reçoit au moins 2 points de règles propres à cette famille. « Corroborée » veut dire « cohérente avec la file nommée », pas « distinguée des autres » : en moyenne, une même combinaison des autres réponses corroborerait 2,4 des cinq déclarations possibles (mesure de la deuxième revue du 8 novembre 2026, avant le passage de la réponse neutre à 1 point)
Déclarée, signaux faibles	la famille déclarée est principale avec moins de 2 points de corroboration
Deux hypothèses	une autre famille dépasse la famille déclarée ; les deux sont montrées
Hypothèse	« je ne sais pas » et une famille atteint au moins 2 points
Pas assez de signaux	« je ne sais pas » et aucune famille n'atteint 2 points ; les deux pistes les moins faibles sont montrées
Pas de file détectée	« rien n'attend » et instabilité non élevée (ou non mesurée)
Instabilité plutôt que file	« rien n'attend » et niveau d'instabilité Élevé, calculé sur les taux d'échec et de reprise (section 3) ; famille principale T, formulée comme un problème de vérification. Une déclaration « tests ou QA » ne donne jamais cette étiquette.

5.4 Égalités

Règle publiée, déterministe, dans cet ordre : (1) la famille déclarée passe en premier ; (2) sinon la famille soutenue par le plus grand nombre de règles distinctes ; (3) sinon la famille la plus en amont du flux : décisions produit, revue, tests, environnements, validations. La phrase de départage est affichée avec le résultat. Pour « Pas de file détectée » et « Instabilité plutôt que file », la famille principale ne dépend pas du classement : il n'y a pas d'égalité à départager.

5.5 Calibration

src/engine/enumerate.ts énumère l'espace des réponses du bloc principal. Les classes sont construites à partir des listes d'options des dix items notés (lead_time, deployment_frequency, recovery_time, change_failure_rate, rework_rate, wait_where, wait_dependency, changes_per_deployment, user_understanding, platform_feedback), « Je ne sais pas » et « Sans objet » compris : chaque option passe par factsFrom, comme dans le moteur, et les options qu'aucune règle ne distingue forment une classe pondérée par leur nombre. Deux tests de src/engine/constraint.test.ts vérifient que l'énumération modélise le moteur livré : 3 000 jeux de réponses tirés au hasard reçoivent de evaluateConstraint et des représentants de leurs classes la même famille principale, la même secondaire, la même étiquette, les mêmes totaux et le même départage ; 12 000 tirages par pondération reproduisent à moins de 2 points les parts d'étiquettes et de familles publiées ci-dessous.

Pondérations :

• uniforme : chaque option a le même poids ; pour les deux taux, chacune des sept tranches des figures 14 et 15 et « Je ne sais pas » pèsent autant (uniforme sur les tranches, pas sur les entiers) ;
• marges DORA : délai, fréquence, rétablissement, taux d'échec et taux de reprise suivent les « % at level » des figures 11 à 15, sans poids pour « Je ne sais pas » ; les autres items restent uniformes ;
• sensibilité, entiers uniformes : les taux sont uniformes sur les entiers de 0 à 100. Publiée, sans assertion.

Résultats de la révision 1, après la deuxième revue du 8 novembre 2026 (en %) :

Mesure	Uniforme (2 359 296 cellules)	Marges DORA (762 048 cellules)
Famille principale R / T / E / G / P / N	15,2 / 18,5 / 18,2 / 27,1 / 12,3 / 8,8	15,7 / 19,5 / 15,8 / 27,9 / 12,2 / 8,9
Déclarée et corroborée	34,2	34,8
Déclarée, signaux faibles	36,7	36,5
Hypothèse	11,3	11,4
Deux hypothèses	4,1	3,7
Pas de file détectée	8,6	8,7
Instabilité plutôt que file	3,9	3,8
Pas assez de signaux	1,2	1,1
P(corroborée | déclarée) R / T / E / G / P	40,6 / 45,1 / 56,6 / 44,3 / 42,9	43,6 / 51,5 / 45,8 / 47,4 / 42,9
P(deux hypothèses | déclarée) R / T / E / G / P	3,9 / 2,3 / 2,0 / 4,3 / 15,8	2,4 / 1,2 / 2,8 / 3,8 / 15,3
Corroborations reposant sur une seule règle R / T / E / G / P	0 / 0 / 13,2 / 9,9 / 100	0 / 0 / 3,7 / 7,8 / 100
Égalités exactes	1,0	0,9
Famille secondaire affichée	33,7	33,3

Sensibilité, taux uniformes sur les entiers : la plupart des entiers tombent dans les tranches larges au-delà de 16 %, si bien que T corrobore dans 84,6 % des déclarations « tests ou QA », devient famille principale dans 32,0 % des cas, et « Instabilité plutôt que file » monte à 10,2 %. Les assertions gardent la convention uniforme sur les tranches, parce qu'une équipe répond la tranche de sa réalité, pas un entier tiré au hasard ; sous les marges DORA, qui sont observées, T corrobore à 51,5 %.

Contrôle sans règles génériques (enumerateCore(…, { genericRules: false }), wait_dependency neutralisé) : P(corroborée | déclarée) est identique, puisque les règles génériques ne comptent jamais dans la corroboration ; « Déclarée, signaux faibles » descend à 35,6 (uniforme) et 35,5 (marges DORA) ; « Deux hypothèses » monte à 5,1 et 4,7.

L'étiquette la plus fréquente est « Déclarée, signaux faibles ». Elle devance « Déclarée et corroborée » de 2,5 points en uniforme et de 1,7 point sous marges DORA. Jusqu'à la deuxième revue, la réponse neutre « 4, ni d'accord ni pas d'accord » à user_understanding valait 2,05 points P et corroborait à elle seule « décisions produit » ; c'est elle qui faisait passer « corroborée » devant. Une réponse neutre n'est pas une preuve : l'ancrage AICM (p. 55, fig. 16) porte sur une orientation utilisateur faible, pas incertaine. Elle vaut désormais 1 point, comme dans la spécification, et ne corrobore qu'avec un second signal P, la durée des tâches du module C. Le bloc principal n'a qu'un item P, et aucun autre de ses items ne renseigne sur les décisions produit sans parler d'IA ou sans répéter la déclaration. Plutôt que d'ajouter des points sans preuve, la révision 1 publie ce résultat. L'assertion de la spécification « l'étiquette modale n'est pas signaux faibles » est remplacée par deux garde-fous : « Déclarée, signaux faibles » reste sous 40 % des verdicts, et à moins de 3 points de « Déclarée et corroborée ».

Assertions tenues sous les deux pondérations, avec et sans règles génériques : P(corroborée | déclarée) dans [35, 65] pour R, T, E, G et P ; les deux garde-fous ci-dessus ; égalités exactes sous 2 % ; chaque famille atteint « Déclarée et corroborée » et « Hypothèse » ; « Instabilité plutôt que file » n'apparaît qu'avec une instabilité Élevée et « rien n'attend » ; « Deux hypothèses » sous 15 %. Sous réponses uniformes, aucune famille ne dépasse 35 % des familles principales.

G pèse plus que les autres comme famille principale parce que deux réponses de wait_where sur huit y mènent (validation de mise en production, revue sécurité). À réponse déclarée égale, les familles ne se corroborent pas toutes aussi facilement : E le plus en uniforme (56,6 %), T sous marges DORA (51,5 %), R le moins en uniforme (40,6 %). E est nourrie par deux items indépendants, le rétablissement et la plateforme (faible ou absente), plus la combinaison délai court et déploiements rares. P ne l'est que par le désaccord sur la compréhension des utilisateurs (1 à 3 sur 7) : 3 réponses sur 7, d'où 42,9 % sous les deux pondérations, et toutes ses corroborations reposent sur cette seule règle. G (44,3 et 47,4 %) est nourrie par la taille des lots et par les déploiements rares. R dépend presque entièrement du délai de mise en production, de la cadence et de la taille des lots, qui signalent une file sans être propres à la revue : environ un quart des corroborations de R reposent sur les seules métriques de livraison (mesure de la deuxième revue). Le module F (first_pass_acceptance) apporte un signal plus spécifique.

Recalibrage par rapport à la spécification initiale (qui ne corroborait la revue que dans 12,6 à 14 % des cas et faisait de « signaux faibles » l'étiquette modale avec une large avance), puis par rapport à la première version de ce moteur (où wait_dependency donnait jusqu'à 1,5 point de corroboration à n'importe quelle famille déclarée) : la dépendance aux autres et l'attente mesurée ne comptent plus que comme preuve qu'une file existe ; les règles propres à chaque famille ont été renforcées : délai lent et délai plus lent que la cadence de déploiement pour R ; taux d'échec et de reprise pour T ; rétablissement, plateforme faible et absence de plateforme pour E ; taille des lots et déploiements rares pour G. Pour P, la deuxième revue a retiré la corroboration par la réponse neutre. La revue est désormais corroborée dans 40,6 à 43,6 % des cas ; « signaux faibles » reste l'étiquette la plus fréquente, mais de 1,7 à 2,5 points.

La première publication de ces chiffres venait d'une énumération qui ne modélisait ni « Sans objet » ni « Je ne sais pas » pour platform_feedback : elle annonçait E à 59,2 et 49,4 % au lieu de 56,6 et 45,8 %. Les classes sont désormais dérivées des options et contrôlées contre le moteur.

Neutralité : aucun item non DORA ne parle d'IA, y compris baseline, qui demande une mesure de référence datée des métriques de livraison ; wait_where demande où le travail attend le plus longtemps, vsm_drawn si l'équipe sait dessiner son flux (test src/content/items.test.ts).

6. Profils d'équipe (module P) — « Estimation »

Le rapport ne publie pas de centres numériques. La lecture est une concordance qualitative entre les huit niveaux de facteurs du visiteur et les niveaux que le rapport énonce en mots pour chaque profil (pp. 16–18), transcrits dans la matrice de src/content/profiles.ts avec leur page (null quand le rapport ne dit rien ; jamais comparé).

Niveaux des facteurs : débit et instabilité de la section 3 ; performance d'équipe et performance produit = moyenne sur 7 points (Bas < 4, Moyen 4 à 5,49, Élevé ≥ 5,5) ; efficacité individuelle = moyenne sur 5 points (Bas ≤ 2,5, Élevé ≥ 3,5) ; travail utile en % (Bas < 40, Élevé ≥ 65) ; friction (options 1–2 Bas, 3 Moyen, 4–5 Élevé) ; épuisement = moyenne sur 5 points (Bas < 2, Élevé ≥ 3).

Accord d'un profil = somme sur les cellules énoncées et mesurées (identique 1, adjacent 0,25, opposé 0) ÷ nombre de ces cellules. Classement par accord, puis nombre de cellules identiques, puis nombre de cellules comparées, puis part du profil dans le rapport, puis numéro du profil. Les deux premiers profils sont affichés avec leurs traits concordants et discordants.

Cellules de la matrice : text quand la page nomme le facteur et son niveau ; inferred quand la page parle d'un indicateur voisin que JDUCRAFT rattache à un facteur ; figure10 quand seul le nuage de la figure 10 (p. 19) situe le profil. Les cellules inferred sont :

Profil	Facteur	Ce que dit la page, en substance	Rattachement JDUCRAFT
Foundational challenges	débit	indicateurs de « livraison produit » bas (p. 16)	débit de livraison
Foundational challenges	performance produit	même phrase (p. 16)	performance produit, la livraison produit couvrant aussi ce que le produit rend aux utilisateurs
Foundational challenges	travail utile	création de valeur basse (p. 16)	part de travail utile
Constrained by process	performance produit	valeur limitée pour le client ou l'entreprise (p. 17)	performance produit (et non travail utile, qui mesure le temps ressenti comme utile par la personne)

Harmonious high-achievers n'a plus de cellule « performance d'équipe » : la page 18 parle de bien-être d'équipe, qui recouvre l'épuisement et la friction, déjà présents comme cellules.

Biais résiduel (énumération des 3^8 = 6 561 combinaisons de niveaux, test src/engine/profile.test.ts) : part en premier choix Foundational challenges 10,4 %, Legacy bottleneck 14,7 %, Constrained by process 13,5 %, High impact, low cadence 12,8 %, Stable and methodical 9,4 %, Pragmatic performers 24,5 %, Harmonious high-achievers 14,6 %. Aucun profil ne dépasse 30 %, tous sont atteignables. Deux causes expliquent la pente vers Pragmatic performers :

1. deux de ses cellules énoncées sont « Moyen » (friction, épuisement) : tout niveau y est au plus adjacent, donc jamais opposé ;
2. 11,8 % des combinaisons laissent les deux premiers profils à égalité d'accord et de cellules identiques ; 11,5 % vont jusqu'à l'étape « part du profil », qui favorise les deux profils à 20 % (Pragmatic performers et Harmonious high-achievers), et 3,2 % jusqu'au numéro du profil, uniquement entre ces deux-là, ce qui donne l'avantage à Pragmatic performers (n° 6).

Stable and methodical est défavorisé pour la raison inverse : il partage quatre de ses six cellules énoncées avec Harmonious high-achievers, dont la part (20 % contre 15 %) l'emporte dans les égalités.

Avertissements DORA affichés avec la lecture : les noms et descriptions des profils sont une interprétation des données (rapport, p. 16) ; les mesures se prennent au niveau de l'application ou du service (p. 20) ; savoir précisément quel profil décrit l'équipe n'est pas essentiel (AICM, p. 72), avec la méthode de conversation de DORA (trois votes anonymes par participant, AICM p. 72).

7. Capacités IA (module C) — « Donnée DORA » à un niveau « Estimation »

Les étiquettes d'effet par niveau (non établi, faible, moyen, fort, hausse ou baisse) sont transcrites des figures 3 à 17 de l'AICM avec leur page (src/content/capabilities.ts). Convention de frontière : quand le repère d'un niveau tombe exactement sur la frontière entre deux segments, la cellule prend l'étiquette la plus prudente, la plus proche de « non établi » ; à moins d'environ 5 % d'une frontière, elle garde l'étiquette du segment sous le repère. L'autre lecture est conservée comme alternative. Le placement des réponses sur l'axe à cinq niveaux est une estimation : l'AICM ne publie pas de définition des niveaux.

8. Code de résultat v2

• Préfixe de version 2, puis un champ binaire compact en base64url : révision du modèle (4 bits), trois drapeaux de modules (P, C, F), puis chaque item du bloc principal dans l'ordre de CORE_ITEM_IDS, puis les items des modules répondus.
• Choix unique : index de l'option + 1 (0 = sans réponse), sur le nombre minimal de bits. Pourcentages : 7 bits, 0 à 100, 101 = « je ne sais pas », 127 = sans réponse. Choix multiple : un bit par option.
• Somme de contrôle : 2 caractères (CRC-16/CCITT réduit à 12 bits) sur le corps. Un code altéré, tronqué, étranger ou vide est refusé avec une raison.
• Révision de la disposition des items (4 bits, actuellement 1) : un code écrit sous une autre révision est refusé (revision) plutôt que lu avec la disposition courante ; une future révision devra fournir sa propre lecture.
• Les pourcentages sont des entiers ; une valeur non entière est écrite comme sans réponse, comme le moteur la lit.
• Aucun nom d'équipe dans le code : il reste dans le stockage local du navigateur.
• Anciens liens v1 (?d= en JSON base64) : les cinq réponses de livraison sont reprises ; une réponse en tranche pour le taux d'échec ou de reprise devient le milieu de la tranche (plus de 64 % → 82, 32–64 % → 48, 16–32 % → 24, 8–16 % → 12, 4–8 % → 6, 2–4 % → 3, 0–2 % → 1) ; les six anciens items d'auto-évaluation sont ignorés et signalés.

9. Ce que ce diagnostic ne dit pas

Les réponses sont déclaratives, d'une seule personne, à un instant donné. Le questionnaire voit des symptômes, pas les causes (DORA 2025, p. 14) : la contrainte probable est une hypothèse à confirmer sur une cartographie de flux. Le but de DORA est l'amélioration continue, pas d'atteindre le haut de la distribution (p. 20).