Statistiques de juin 2026 : sources, méthode et limites

Que mesurent les chiffres de l’accueil ?

Les statistiques de Singularity sont un retour d’expérience interne de Meteor Factory pour la semaine du 8 au 14 juin 2026 : 227 tickets déclarés terminés, 86 tickets hors bugs, 11 projets, un pic rapporté de 8 agents et 2,1 messages par ticket. Ce sont des valeurs historiques rapportées, pas un benchmark indépendant, une moyenne de nos clients ou une promesse de productivité. Cette étude de cas est documentée le 10 octobre 2026.

Quelles sources permettent de les vérifier ?

La source éditoriale est le commit Impacts 4a7f59ae230542ccfac4eb127fd76f3a60e2717c, daté du 21 juin 2026, qui attribue ces agrégats au bilan hebdomadaire Singularity et précise 5 espaces de travail, 227 tickets terminés et 141 bugs corrigés. L’année de la période est reconstituée à partir de cette date. Les 86 tickets hors bugs correspondent à 227 − 141 : les appeler tous « features » était trop précis, car ce solde peut aussi contenir de la documentation ou du refactoring.

Une présentation publique sur Product Hunt, consultée le 10 octobre 2026, reprend ces ordres de grandeur dans un commentaire du cofondateur. C’est une déclaration de l’éditeur sur une plateforme tierce, pas une validation indépendante.

Le fonctionnement du bilan est présenté dans l’article sur le bilan hebdomadaire. Sa capture et ses autres chiffres portent sur un autre bilan : ils ne valident pas la semaine de juin. La référence technique consultée le 10 octobre 2026 est src/modules/gamification/main/domain/weekly-report-service.ts dans le dépôt Singularity. Elle agrège les tables locales kanban_tasks, orchestration_runs, run_worktrees et task_feedback.

Le dépôt du site ne contient ni export figé de la base de juin, ni numérateur et dénominateur de la moyenne 2,1, ni fuseau horaire enregistré pour cette extraction. Nous ne pouvons donc pas recalculer ou certifier rétrospectivement ces valeurs. Les règles ci-dessous décrivent la méthode actuelle, pas une preuve que la version de juin appliquait exactement les mêmes filtres.

Qu’est-ce qu’un ticket livré dans ce bilan ?

Un ticket livré désigne ici un ticket au statut done avec une date de clôture done_at dans la fenêtre étudiée. Il est compté une seule fois par identifiant. Ce statut n’atteste pas à lui seul d’un déploiement en production, de l’absence de bugs ou d’une validation client. Les tickets ouverts, en cours, en échec, annulés ou rouverts sans nouvelle clôture sont exclus. Après réouverture puis clôture, la date de dernière clôture détermine la semaine retenue.

Comment reproduire les agrégats sans partager de données clients ?

Travaillez sur une copie locale figée de votre propre base, en lecture seule. Fixez la version de Singularity, la date d’extraction et le fuseau de la machine : le service calcule les semaines du lundi à 00 h au lundi suivant à 00 h, borne de fin exclue. Pour reproduire la période annoncée, utilisez le 8 juin 2026 à 00 h et le 15 juin à 00 h dans le fuseau choisi ; le fuseau historique reste inconnu. Gardez les identifiants uniquement en local pour dédupliquer.

1. Tickets et bugs : sélectionnez les lignes de kanban_tasks avec status = 'done' et début ≤ done_at < fin. Comptez les identifiants uniques ; les bugs sont le sous-ensemble type = 'bug'. Le solde hors bugs est total − bugs. Pour mesurer de véritables features, filtrez séparément type = 'feature' au lieu d’assimiler tout le solde à des fonctionnalités.
2. Projets : sélectionnez les exécutions de orchestration_runs où updated_at ≥ début et created_at < fin. Comptez l’union des target_id ciblant un projet et des project_id de leurs run_worktrees, sans doublons. Ce périmètre couvre la base locale, pas l’ensemble des installations Singularity.
3. Pic de parallélisme : pour ces exécutions, bornez chaque intervalle à la semaine, ignorez les intervalles vides et comptez le maximum de chevauchements. À timestamp égal, traitez les fins avant les débuts. Le résultat est un indicateur d’exécutions simultanées, pas un nombre de fournisseurs IA distincts ni une mesure exacte du temps CPU actif.
4. Messages par ticket : dans task_feedback, filtrez début ≤ created_at < fin, groupez par task_id, puis divisez le nombre de lignes par le nombre de tickets ayant au moins une ligne. Chaque entrée stockée compte, y compris réponses et résultats/questions MCP ; ce n’est pas uniquement le nombre de prompts humains. Les tickets sans message sont exclus du dénominateur. Arrondissez à une décimale seulement à l’affichage. Le dénominateur n’est pas nécessairement le nombre de tickets terminés.

Pour publier un résultat reproductible, conservez avec la copie locale la version du calcul et les bornes temporelles, puis exportez uniquement les totaux, le nombre de bugs, le nombre de features, le nombre de projets distincts, le pic, le total de messages et le nombre de tickets avec messages. Excluez de l’export public les noms de clients, titres de tickets, identifiants, chemins de dépôts, prompts, réponses et code. Une base manquante ou une colonne indisponible n’est pas une preuve d’activité nulle : le service peut retourner une valeur de repli ; signalez la donnée comme non vérifiée.

Quelles conclusions peut-on en tirer ?

Le périmètre historique déclaré couvre une utilisation interne sur 5 espaces de travail et 11 projets ; la composition détaillée et les éventuelles exclusions de jeux de démonstration ne sont pas conservées dans la source éditoriale. Aucun groupe témoin, échantillonnage client, mesure de complexité ou audit externe ne permet d’attribuer un gain causal à Singularity. Les chiffres décrivent l’activité rapportée d’une semaine. Consultez le cycle de vie des tickets et le guide de l’orchestration pour comprendre le workflow, puis essayez-le sur votre propre projet.