← Tous les articles

La gamification dans Singularity : produire plus, mais surtout produire mieux

Je ne crois pas aux tableaux de bord qui flattent. Je crois aux chiffres qui dérangent juste assez pour me faire changer quelque chose la semaine d'après.

C'est exactement ce que fait « Your week in review » dans Singularity : un bilan hebdomadaire qui s'ouvre tout seul et qui me dit, sans détour, ce que j'ai produit, comment je l'ai produit, et ce que ça a coûté. Pas pour me donner une note. Pour me donner une direction.

Le panneau 'Your week in review' de Singularity : économies RTK, tickets terminés, bugs corrigés, tickets ouverts, heures travaillées, round trips, tokens et agents IA utilisés sur la semaine
Le bilan de la semaine dans Singularity : économies RTK en haut, puis tickets terminés, bugs corrigés, tickets ouverts, projets, parallélisme, heures travaillées, et le détail messages / round trips / tokens / agents IA.

Pourquoi gamifier le travail d'un développeur

La gamification a mauvaise presse parce qu'on l'a trop souvent réduite à des badges inutiles. Ici, l'idée est inverse : ne pas récompenser l'activité, mais rendre visible le progrès. Un développeur qui voit sa courbe s'améliorer change de comportement de lui-même — sans manager dans le dos, sans objectif imposé.

Singularity ne me demande pas de « faire plus ». Il me montre ce que « mieux » veut dire, chiffres à l'appui, et me laisse en tirer mes propres conclusions.

Produire plus, mais produire mieux

La semaine du bilan ci-dessus raconte une histoire précise. 361 tickets ouverts (+73 %), mais seulement 98 bugs corrigés (−62 %). Au premier regard, on pourrait croire que je corrige moins. La vérité est l'inverse : j'ouvre de plus en plus de tickets de feature, et de moins en moins de tickets de bug.

Moins de bugs à corriger, ce n'est pas moins de travail : c'est le signe d'un code qui s'assainit. La gamification de Singularity met cette tendance noir sur blanc, semaine après semaine, là où d'habitude on ne la « sent » que vaguement.

C'est ça, « produire plus mais produire mieux » : la quantité de valeur livrée monte pendant que la quantité de dette qu'on doit éponger descend.

La métrique qui dit la vérité : combien de fois je rouvre un ticket

De toutes les statistiques de l'écran, celle que je regarde en premier, c'est les « round trips » : combien de fois je rouvre un ticket pour le faire continuer. Sur cette semaine, 0,4 aller-retour en moyenne, avec un pic à 9 sur le ticket F-360.

Un ticket rouvert neuf fois, ce n'est pas une IA qui a échoué neuf fois. C'est une tâche que j'ai mal cadrée : périmètre flou, critères d'acceptation imprécis, contexte manquant. Le round trip est le miroir le plus honnête de ma propre rigueur en amont. Plus mon ticket est net, moins j'ai à y revenir.

La moyenne des messages par ticket (1,6) raconte la même chose sous un autre angle : un ticket bien posé se résout en une passe, pas en une conversation interminable.

Tout compte : agents, tâches, et tokens préservés

Le bilan ne se limite pas à « ce que j'ai fait ». Il compte aussi qui l'a fait : sur la semaine, Claude a été sollicité 944 fois, devant Copilot, Codex, Cursor, Gemini et un modèle local Ollama. Voir la répartition réelle entre agents, c'est comprendre où chaque IA est la plus utile — et arrêter de tout envoyer au même modèle par habitude.

Et puis il y a la ligne qui me tient le plus à cœur : les économies RTK. RTK (Rust Token Killer) filtre la sortie verbeuse des commandes avant qu'elle n'atteigne le modèle. Sur cette seule semaine : 143,9 k tokens préservés, un taux d'économie de 73,6 %, sur 1 061 commandes. Des tokens que je n'ai pas payés, un contexte que je n'ai pas pollué, et un agent qui reste concentré sur l'essentiel.

Quand on orchestre plusieurs IA en parallèle toute la journée — ici jusqu'à 9 tâches simultanées au pic — ce genre d'économie n'est pas un détail. C'est la différence entre un atelier qui scale et une facture qui explose.

L'amélioration continue : pour moi, pour Singularity, pour tous

Ce bilan a trois lecteurs.

Moi d'abord. Je vois où je me disperse, quels tickets je cadre mal, quelles heures je travaille vraiment. Je corrige la semaine suivante.

Singularity ensuite. Ces métriques nourrissent le produit : si un type de ticket génère systématiquement des round trips, c'est un signal pour améliorer l'enrichissement automatique des tickets ou les profils d'agents.

Tous, enfin. Chaque utilisateur qui s'améliore rend l'outil meilleur pour le suivant. C'est une boucle vertueuse : mesurer, comprendre, ajuster, recommencer. La gamification n'est que le moteur qui fait tourner cette boucle sans qu'on ait besoin d'y penser.

Foire aux questions

Qu'est-ce que « Your week in review » dans Singularity ?

C'est un bilan hebdomadaire automatique de votre activité de développement : tickets terminés, bugs corrigés, tickets ouverts, heures travaillées, round trips par ticket, tokens consommés, agents IA utilisés et économies RTK. Il s'ouvre seul pour rendre votre progrès visible sans effort.

Que mesure la métrique « round trips » ?

Elle compte combien de fois vous rouvrez un même ticket pour le faire continuer. Un nombre élevé signale en général un ticket mal cadré (périmètre flou, critères imprécis) plutôt qu'un échec de l'IA. C'est un indicateur de la qualité de votre cadrage en amont.

Qu'est-ce que les économies RTK ?

RTK (Rust Token Killer) filtre la sortie verbeuse des commandes (builds, tests, git, etc.) avant qu'elle n'atteigne le modèle. Le bilan affiche les tokens préservés, le taux d'économie et le nombre de commandes filtrées sur la semaine — souvent 60 à 90 % de réduction sur les opérations courantes.

La gamification impose-t-elle des objectifs de productivité ?

Non. Singularity ne fixe aucun quota. Le bilan rend le progrès visible et laisse chacun en tirer ses conclusions. L'objectif est l'amélioration continue, pas la pression chiffrée.