TPC
    TPC
    Tech

    GitHub with AI : ce qui t'ouvre les portes des top startups

    Gabriel Sayar (Software Engineer chez CarbonFact, ex-contributeur EDX UI) et Florian Bruniaux (Founding AI Engineer chez Méthode Aristote, principal contributeur RTK) ont passé en revue une centaine de repos GitHub soumis par la communauté TPC. Ce GitHub Roast, spéciale ère IA, est un retour terrain brut sur ce que les recruteurs et les développeurs actifs en open source regardent vraiment.

    9 min de lecture
    Gabriel & Florian

    Une centaine de repos soumis. Cinq sélectionnés. Deux regards croisés : celui du recruteur (Gabriel) et celui du contributeur open source actif (Florian). Le live alterne entre l'analyse concrète de chaque projet et des règles générales qui s'appliquent à tous les profils. Le message de fond : avec l'IA, tout le monde peut shipper du code. Ce qui fait la différence, c'est la communication, la cohérence et la capacité à identifier un vrai problème.

    1. L'outil créé par Florian pour analyser l'audience d'un repo GitHub

    Avant de passer aux repos analysés, Florian présente StarMapper, l'outil qu'il a construit et qui a servi à préparer ce live.
    L'idée de départ : en travaillant sur RTK, il voulait comprendre qui étoilait le projet. Pas juste le nombre de stars, mais la distribution géographique, les entreprises représentées, et l'influence des personnes qui ont liké. "Si un CTO d'une super boîte a liké, ce n'est pas la même chose que si c'est André Carpati."
    StarMapper récupère les données disponibles via l'API GraphQL de GitHub (gratuitement, avec un token gratuit) et les visualise sur une carte mondiale avec des filtres. Fonctionnalités : voir les clusters de stargazers par pays, ville ou entreprise, filtrer par nombre de followers GitHub pour identifier les "gros poissons", suivre la courbe de croissance des stars dans le temps, et calculer un "Organic Score" — un indicateur de santé du repo basé sur le nombre de forks, de watchers, de releases et de contributeurs, pour détecter les stars achetées.
    "Il y a même un article qui expliquait les différents indicateurs pour identifier qui a triché et qui n'a pas triché. Je me suis inspiré de ce papier."
    Les usages identifiés : motiver les mainteneurs en phase de démarrage, identifier des contributeurs potentiels à proximité géographique, montrer la traction à des investisseurs, permettre aux recruteurs de voir si un client utilise le projet.
    "Moi, typiquement pour RTK, j'en ai vu certains qui avaient liké le repo. Je me suis tapé le culot d'aller les pinguer sur LinkedIn en disant 'Hey, tu as liké le repo, qu'est-ce qui t'a intéressé ?'"
    StarMapper est open source, sorti environ deux mois avant le live.

    2. Ce que Gabriel regarde, ce que Florian regarde

    Avant d'entrer dans les repos, Gabriel et Florian posent leurs grilles de lecture respectives.
    Gabriel (prisme recruteur). Il cherche ce qu'il appelle le "product engineering" — quelqu'un capable de coder et de raconter pourquoi. "C'est la partie communication comme ça, de dire OK, c'est un vrai projet, voilà comment l'utiliser, voilà comment ça marche, ça me donne un signal que tu n'es pas juste capable de coder, tu es aussi capable de présenter."
    Avec l'IA, la qualité technique pure est plus difficile à évaluer rapidement. Ce qui différencie, c'est la capacité à articuler ses propres mots — pas un README généré par IA. "Autant utiliser l'intelligence artificielle pour parler à des machines, fais-toi plaisir. Autant prouver que tu es capable d'articuler tes propres mots."
    Florian (prisme contributeur). Il regarde la santé du projet : est-ce qu'il vit ? Y a-t-il des issues ouvertes par d'autres ? Des PR de contributeurs extérieurs ? "Est-ce que le projet vit ? Qui contribue ?" Il cherche aussi à identifier l'intention derrière le repo. "Est-ce qu'elle vend quelque chose ? Est-ce qu'elle cherche à se faire recruter ? Est-ce qu'on arrive à identifier les sujets auxquels la personne fait attention ?"
    Les deux partagent un signal d'alerte commun : le em-dash dans les descriptions. "Ça, c'est parce que je les chasse. Le em-dash, c'est le marqueur le plus connu du texte généré par IA. C'est bête, ça ne dit rien sur la qualité du projet. Mais il y a des gens qui vont dire 'OK, c'est mort.' Ça prend dix minutes à corriger avec un skill."

    3. Ruby, deux cents stars, et un angle souveraineté qui parle aux recruteurs

    Le premier repo analysé est une plateforme MCP pour la recherche augmentée sur des documents, en self-hosted, développée en Ruby. Deux cents stars environ, deux ans d'existence, commits récents au moment du live.
    Ce que Gabriel apprécie : un README clair, des vidéos screencast intégrées, une organisation lisible. "Je peux voir qu'il y a un produit entier qui a été construit, que ce n'est pas juste un jouet, une exploration d'un soir. Il y a eu un effort, une volonté de rendre ça présentable et accessible."
    L'angle self-hosted : "Il y a cet aspect sécurité et gouvernance des données. On fait tourner ça chez soi, on garde le contrôle sur ses données, on évite d'envoyer tout ça ailleurs." Florian note que l'angle souveraineté est "un conversation starter incroyable", que ce soit en recrutement ou en prospection.
    Sur le Ruby : "Maîtriser sa techno, quelque part, c'est bien. Et c'est vrai que Ruby est assez sous-représenté dans les projets IA."
    Le point constructif : le repo semble en stand-by. "Si on veut garder un repo comme vitrine, il faut le mettre à jour. Sinon, très vite, on a l'impression qu'un projet est laissé à l'abandon." Suggestion de Florian : ajouter une note explicite dans le README — projet en pause, objectif atteint, ou maintenance minimale assumée. "N'importe qui peut comprendre ça. L'open source, c'est très chronophage."

    4. La communication comme variable

    Le deuxième repo est un outil de code review automatisée par IA, avec plusieurs agents spécialisés (back, front, architecture), récent et maintenu activement — des commits la veille du live.
    Ce que Florian apprécie : l'architecture multi-agents, dans l'air du temps, "un truc parmi les choses les plus game changer qu'on peut faire maintenant." Les diagrammes dans le README : "Même en étant fainéant, en gros, on arrive à capter ce que ça fait sans tout lire."
    La question posée : pourquoi peu de stars pour un projet aussi pertinent ? Florian identifie deux causes probables. Un README avec des em-dashes — "ça veut vraiment dire que c'est AI-generated. Ce n'est pas ce qui me bloque, mais il y a des gens qui vont dire OK, c'est mort." Et surtout : le manque de communication externe.
    "On n'a pas énormément vu ce projet passer sur LinkedIn, Reddit, Hacker News. Il y a le savoir-faire et il y a le faire savoir." Pour RTK, "c'est un post Reddit, je pense, qui a eu le droit de limite de vie ou de mort sur le projet."
    Gabriel ajoute un signal positif important : l'auteur semble utiliser lui-même l'outil. "Si c'est un outil qu'il a créé pour son propre usage et qui répond à son propre besoin, pour moi, c'est un gros plus." Le commentaire constructif final : trouver la bonne fenêtre pour communiquer. "Les coûts en tokens, c'est un sujet brûlant. C'est là la window opportunity pour advocater."

    5. Quand un profil entier est plus fort qu'un repo isolé

    Le troisième cas est un profil complet plutôt qu'un repo unique : un développeur avec plusieurs projets interconnectés en Rust (dont un langage de programmation maison, un key-value store, une plateforme de partage de projets), une identité cohérente à travers le naming (même préfixe sur tous les projets), et des publications sur Hugging Face et Medium.
    Gabriel : "Quand j'arrive sur ce profil, je sais que la tech, ça ne va pas être le problème. Il y a du Rust, il y a le propre langage de programmation. Ce ne sont pas ces questions que je vais poser." Ses questions suivantes portent sur le "pourquoi" : ce langage maison, est-ce qu'il résout un vrai problème ?
    Le revers : dans un contexte startup early stage qui va vite avec peu de ressources, "c'est presque un red flag des gens qui aiment beaucoup la technique et qui ne sont pas forcément capables de savoir quand s'arrêter. Une force peut aussi devenir quelque chose à confirmer ou à flaguer différemment en fonction du profil qu'on recrute."
    Florian souligne la DA claire. "On sait avec qui tu parles, on sait quelles sont les motivations." Un point constructif mineur : des em-dashes dans certaines descriptions.

    6. Un signal de passion avant tout

    Le quatrième profil est celui d'un développeur en reconversion — ingénieur géologue de formation — avec une vingtaine de repos d'exercices (clone Airbnb, clones d'apps connues), des commits récents et un profil README soigné.
    Gabriel : "Mon GitHub, c'est mon CV. La quantité de projets que je vois, c'est assez intéressant." Le signal principal : si quelqu'un envoie des commits et des pull requests sur son temps libre, en parallèle d'une reconversion, "a priori, sur le papier, c'est quelqu'un qui doit être plus motivé que quelqu'un qui n'aura pas ça."
    Les points constructifs de Florian : des commits en français ("il faut toujours respecter certaines bonnes pratiques — l'anglais dans les commits, et des commits bien clairs qui décrivent ce que tu as ajouté ou modifié"). Un manque de README sur les repos individuels. Et l'idée d'ajouter un cheminement narratif dans la doc — "avec tel projet, j'ai travaillé mes skills back-end. Avec tel projet, j'ai voulu travailler le design."
    Sur la visibilité : "Quand on est dans un objectif de trouver un boulot, il faut prémâcher. Quand on va vous googler, il faut qu'on puisse vous trouver assez facilement. Lier GitHub, LinkedIn, portfolio — c'est du SEO, très concrètement."

    7. Ce que Gabriel et Florian appliquent à tous les profils

    À travers les cinq repos analysés, plusieurs principes reviennent systématiquement.
    Favoriser les images et diagrammes. "Maintenant, quelqu'un qui va donner quelques minutes de temps de cerveau, il faut qu'il screen très vite. Favoriser les images, les vidéos, les diagrammes, les bullet points plutôt que des gros pavés."
    Ajouter un llm.txt pour les projets techniques. "C'est le README machine. Par contre, on peut balancer du contenu comme un port. C'est l'IA qui est écrit à l'IA. C'est une façon intelligente de s'adapter à l'audience."
    Garder le repo actif ou expliquer l'inactivité. Un repo en stand-by sans explication donne l'impression d'un projet abandonné. "L'objectif a été atteint ? C'était d'être recruté, j'ai été recruté ? Dans ce cas, dites-le."
    Communiquer à l'extérieur. "Il y a le savoir-faire et il y a le faire savoir. Et c'est une compétence à part entière." Reddit, Hacker News, LinkedIn — c'est ce qui crée la traction, pas juste la qualité technique.
    Profil README GitHub. "Ça remonte sur le profil public. Je vous encourage à l'exploiter parce qu'il y a beaucoup de gens où on ne voit rien."
    Commits conventionnels. Fix, feat, chore — une convention qui "va souvent refléter aussi les hard skills d'un développeur et savoir s'il a déjà travaillé en équipe."

    "La partie communication humain-à-humain, c'est là où vraiment tu dois mettre tes propres mots. Prouver que tu es capable d'articuler tes propres mots, quitte à en mettre moins. Ça, c'est sur les descriptions, sur les taglines, sur les communications de recruteurs."

    Gabriel Sayar, Software Engineer, CarbonFact

    "Il y a le savoir-faire et il y a le faire savoir. RTK avait décollé avec un post Reddit. Je pense que c'est ce post qui a eu le droit de limite de vie ou de mort sur le projet."

    Florian Bruniaux, Founding AI Engineer, Méthode Aristote

    8. Replay du live

    Vous recrutez ce profil ?

    TPC vous accompagne pour trouver des profils adaptés à vos besoins.

    Découvrez aussi notre pôle Engineering et son accompagnement dédié.