Résumé

Ce générateur de rapport IA estime combien de temps un nouvel ingénieur met à livrer sa première PR significative, et à quel point un codebase est risqué à prendre en main, à partir de cinq inputs : lignes de code, contributeurs actifs, couverture de tests, âge du codebase et style de typage. La formule est une heuristique transparente construite sur des études publiées de code review et de sondages développeurs (les études Google/SmartBear sur la taille des reviews, le rapport Developer Coefficient de Stripe) : pas une boîte noire. Tout tourne côté client, rien de ton codebase n'est envoyé où que ce soit.

Un générateur de rapport IA pour l'onboarding et le risque d'un codebase

Renseigne les lignes de code, la couverture de tests, la taille de l'équipe et l'âge du repo. Tu obtiens un rapport en clair à coller dans une description de PR ou un thread Slack : pas d'inscription, pas d'aller-retour serveur.

Essayer maintenant

Générateur de rapport IA pour codebase

Renseigne les stats de ton codebase ci-dessous. Le rapport se met à jour en direct et tu peux le copier en texte brut.

Temps d'onboarding estimé -
Score de risque du codebase - -

À corriger en premier

    Comment le rapport calcule ça

    Ce qui entre dans l'estimation

    Taille et couverture

    Le temps d'onboarding grimpe avec le nombre de lignes de code, et empire nettement sous les 50% de couverture de tests : reviewers et nouveaux arrivants finissent par lire l'implémentation ligne par ligne au lieu de faire confiance à la suite de tests.

    Bande passante de l'équipe

    Une équipe de moins de 5 contributeurs actifs n'a pas de filet de sécurité informel : une question sans propriétaire évident traîne dans un DM pendant une journée. Au-delà d'environ 15 contributeurs, la bande passante de mentorat cesse d'être le goulot d'étranglement et c'est le codebase lui-même qui prend le relais comme facteur limitant.

    Âge et typage

    Passé 3 à 7 ans, un codebase accumule une connaissance tribale qui n'a jamais atterri dans les commentaires ou la doc : conventions de nommage, modules dépréciés que personne n'a supprimés, contournements pour un bug corrigé ailleurs. Le typage statique (TypeScript, Go, Rust, Java) réduit le temps de montée en compétence par rapport aux langages dynamiques, parce que les types font aussi office de documentation.

    Prends la température avant d'assigner le ticket

    Un score de risque est un point de départ pour discuter avec ton équipe des vrais goulots d'étranglement, pas un verdict gravé dans le marbre : sers-t'en pour décider quoi corriger avant l'arrivée du prochain recrutement, pas pour classer les ingénieurs.

    Gros plan de mains tapant sur un clavier avec un écran de laptop montrant des widgets de rapport abstraits et flous

    Questions fréquentes

    Est-ce que c'est gratuit ?
    Oui. Le générateur de rapport tourne entièrement dans ton navigateur : pas d'inscription, pas de paywall, et aucune donnée envoyée à un serveur pour calculer l'estimation.
    D'où viennent ces repères chiffrés ?
    La formule est une heuristique transparente, pas un modèle peer-reviewed. La recommandation sur la taille des PR (rester sous environ 400 lignes, l'efficacité chute après environ 60 minutes de lecture continue) vient de la documentation sur les pratiques d'ingénierie de Google et de l'étude de code review SmartBear/Cisco. L'ampleur des pénalités liées à la couverture et à la dette technique s'appuie sur le rapport Developer Coefficient de Stripe, qui a mesuré qu'une grosse partie de la semaine des ingénieurs part dans du mauvais code et du travail de maintenance. On l'appelle une heuristique volontairement : prends le chiffre comme une indication, pas comme une valeur exacte.
    Est-ce que les données de mon codebase sont envoyées quelque part ?
    Non. Chaque input reste dans ton navigateur et le calcul tourne en JavaScript sur ton appareil. La seule activité réseau est un ping anonyme qui compte les utilisations du widget, sans aucun détail sur ton codebase.
    Est-ce que ça remplace un vrai plan d'onboarding ?
    Non. Ça te donne un chiffre de départ pour planifier : un nombre de jours approximatif et un niveau de risque. Complète-le avec une vraie checklist d'onboarding, un mentor assigné, et une liste de lecture de la première semaine construite depuis ton propre repo.
    Pourquoi mon score de risque est plus élevé que prévu ?
    Trois facteurs le font grimper le plus vite : une couverture de tests sous les 30%, un codebase de plus de 7 ans, et un ratio élevé de lignes de code par ingénieur. Regarde ces trois-là en premier : ce sont généralement ceux que tu peux vraiment corriger ce trimestre.
    Et si mon repo est un monorepo avec plusieurs langages ?
    Fais tourner les chiffres pour le langage et la zone que le nouvel arrivant va réellement toucher en premier, pas pour tout le monorepo. Un monorepo de 2 millions de lignes où un junior ne travaille que dans un service de 40K lignes devrait être scoré sur ce service, pas sur le repo entier.
    Est-ce que je peux aussi m'en servir pour planifier la capacité de code review ?
    Partiellement. Le score de risque est corrélé à la charge de review : un codebase à haut risque veut souvent dire des reviews plus lentes et plus coûteuses, mais ça ne remplace pas la mesure réelle du cycle time des PR de ton équipe dans ton propre dashboard de métriques.
    En quoi le score de risque diffère de l'estimation d'onboarding ?
    Le temps d'onboarding répond à la question : combien de temps avant qu'un nouvel ingénieur soit productif. Le score de risque répond à une autre question : à quel point le codebase est fragile en général. Une faible couverture de tests et un codebase vieillissant et concentré font monter le risque même pour des ingénieurs présents depuis des années.

    Transforme ce rapport en deck d'onboarding

    Skywork transforme des notes brutes en slides, docs et diagrammes : pratique pour le pack d'onboarding que personne n'a le temps de designer à la main quand un nouvel ingénieur arrive lundi.