Foire aux questions

Non — aucun suivi du temps, aucun écran, aucune frappe. Nous analysons uniquement les modifications de code elles-mêmes et estimons leur difficulté cognitive en heures d''un développeur de référence. C''est un étalon, pas une feuille de temps.

Le temps que prendrait la modification à un développeur de niveau intermédiaire (3 à 4 ans) qui connaît le code et travaille sans IA. Cela mesure la difficulté du travail — pas les lignes, ni le temps réellement passé au bureau. Cela couvre l''écriture du code, les tests manuels et les corrections de revue ; cela exclut les réunions, la planification et l''attente de revue.

Ce n''est pas « un appel à un réseau de neurones » mais un pipeline multi-étapes dans lequel l''IA n''est qu''une couche. D''abord, un modèle lit les modifications de code elles-mêmes — ce qui a réellement changé — et juge la difficulté cognitive pour un développeur de référence, plutôt que de compter les lignes ou les commits. Par-dessus s''exécute une couche algorithmique déterministe : le système classe la nature de chaque modification, reconnaît séparément le travail à fort enjeu (par exemple infrastructure, migrations de données, sécurité), filtre les modifications mécaniques et générées (recherche-remplacement de masse, code généré et déplacé, mise en forme), et applique des ensembles de règles de correction et des garde-fous afin qu''une supposition isolée d''un modèle ne puisse pas faire dévier le résultat. Les commits volumineux et combinés sont traités plus en détail. Le même standard est appliqué automatiquement à tout le monde, chaque commit est évalué une seule fois et le résultat est figé — d''où la comparabilité et la reproductibilité.

Elle est née du développement réel en entreprise : la couche algorithmique encode des schémas empiriques recueillis sur de vrais projets — quelles modifications coûtent généralement plus qu''elles n''en ont l''air, et lesquelles sont peu coûteuses malgré leur taille. Ces règles sont vérifiées par rapport à de vraies estimations de référence (calibration). Le système se comporte donc davantage comme un responsable technique expérimenté évaluant le travail que comme un simple compteur de lignes.

Au contraire — c''est tout l''intérêt. Nous comparons votre équipe à un développeur de référence qui travaille sans IA ; si l''IA vous permet de livrer davantage par jour, le Ghost% augmente, et cet écart par rapport à la « norme pré-IA » est exactement ce que le produit montre. Ce n''est pas une distorsion — c''est le résultat.

Le rapport entre votre production quotidienne et celle du développeur de référence. 100 % correspond au niveau de la référence, plus signifie que vous livrez davantage par jour, moins signifie moins. Ce ne sont ni des heures ni des heures supplémentaires : un chiffre élevé ne signifie pas « épuisement », et un chiffre faible ne signifie pas à lui seul « faible ».

C''est un modèle, pas une mesure. Personne ne peut reconstituer le temps réel, la valeur réside donc dans un seul ensemble de règles pour tout le monde : solide pour les tendances et les comparaisons, pas pour une précision à l''heure près pour une seule personne. Un outil pour poser de meilleures questions, pas pour rendre des verdicts.

Diviser et combiner des commits ne la fait pas bouger de façon significative — ce qui est évalué, c''est la substance et la difficulté des modifications, pas le nombre de commits ou de lignes. Plus important encore : toute métrique sur laquelle on cible directement les gens finit par être optimisée à la place du travail. Utilisez-la donc comme un signal et une tendance d''équipe, pas comme un KPI personnel — il n''y a alors rien à détourner.

Le système voit le code, pas l''ensemble du rôle : la conception, les revues, le mentorat, la planification et les réunions ne sont pas dans l''estimation. Un écart signifie souvent qu''une grande partie de la valeur d''une personne se situe en dehors des commits — ce qui mérite en soi d''être remarqué.

Pas de lui-même : il ne voit que le code et ne connaît ni le rôle réel ni la charge de travail d''une personne (revues, mentorat, réunions, support). Seul le manager connaît la charge de travail complète. C''est à cela que sert le paramètre Share — la part de temps qu''un employé consacre réellement à écrire du code (0–100 %). Par défaut, elle est de 100 % (nous supposons que la personne se consacre entièrement au code) ; le manager l''abaisse manuellement pour refléter le travail hors code — c''est là que le contexte absent du code entre dans le système. La comparaison avec la référence devient alors équitable, y compris pour ceux qui ne codent pas toute la journée.

Pas de lui-même. C''est un signal d''équipe et une tendance pour amorcer une conversation, pas un verdict individuel : une seule métrique ne saisit ni la qualité, ni l''impact, ni le contexte.

Le coût correspond approximativement à ce qu''a coûté le travail livré à un taux standard ; la valeur correspond approximativement à ce qu''il en coûterait pour reproduire ce volume à la main, sans IA. L''écart entre les deux est un indicateur approximatif de l''effet de levier (outils/IA), pas un compte de résultat.