J’ai posé 27 questions en 60 minutes.
Pas pour meubler. Pour faire parler la personne qui code, qui ragequit, qui reconstruit. (Claire Morel de l’Atelier Rouge m’a offert des réponses cash — et des screenshots.)
Le truc, c’est que les interviews de devs indés sont souvent platoniques : phrases convenues, comms millimétrée, phrases marketing.
Là, j’ai voulu autre chose. Brut, précis, chiffré. Et tu vas voir pourquoi ça marche mieux pour le lecteur et pour le référencement.
💡 Conseil : prépare exactement 5 questions ouvertes et 3 relances techniques (durée moyenne : 45–75 minutes). C’est le sweet spot pour une interview utile.
H2 : J’ai commencé par une anecdote qui a débloqué 2 minutes de confession
Je commence toujours par une histoire stupide.
Pas un “bonjour”, pas une phrase bateau. Une anecdote courte, relatable. (Ça détend et ça donne de la vie.)
Avec Claire, c’était : “Ton jeu plante toujours quand on fait un alt-tab avec la fenêtre Steam overlay active?”
Elle a ri. Elle a répondu en 90 secondes sur un bug de 0.9% des runs mais qui faisait rager les streameurs.
Résultat : elle s’est ouverte sur le code legacy et sur la décision de rewritter 10 % du moteur en 2025.
Anecdote = confiance.
Confiance = réponses concrètes (noms de fichiers, lignes de code, dates).
C’est ce que veut Google : contenu utile, original, qui cite des faits.
H2 : La partie chiffres : 3 metrics précis que j’ai obtenus en 20 minutes
Je ne supporte pas les interviews vagues.
Donc j’ai demandé des métriques. Direct.
- Nombre d’heures de dev depuis le prototype : 4 200 h (cumul équipe de 6).
- Taux de crash en beta closed : 7 % sur 1 200 sessions.
- Taille du patch 1.04 : 45 Mo, déployé en 14 jours.
Ces chiffres changent tout.
Ils t’obligent à écrire des phrases qui contiennent des faits. Et les faits, Google aime ça. (Oui, les bots lisent les chiffres comme des preuves.)
⚠️ Attention : ne cite pas des métriques si tu ne peux pas les sourcer en interne. La crédibilité descend plus vite qu’une mise à jour ratée.
H2 : Le vrai sujet, c’est le crunch — 2 dates et une décision saine
Je lui ai posé la question que tout le monde pense sans oser la dire : “Vous avez crunché ?”
Réponse : oui, fin 2023, pendant 6 semaines.
Puis elle m’a dit la décision prise en janvier 2024 : contrat freelance pour 1 mois à 1 200 € / semaine pour finir le level design, et embauche d’un QA en remote à 900 € / mois.
C’est rare d’avoir des chiffres et des décisions RH dans une interview indie.
Bon, concrètement, ça veut dire quoi ?
Que le studio a choisi de payer pour accélérer sans torcher la santé mentale de l’équipe. (Oui, c’est possible.)
H2 : Gameplay vs monétisation : 1 principe simple qui évite le bad PR
Claire n’aime pas le pay-to-win. Point.
Ils ont choisi un modèle : DLC cosmetic à 9,99 € + season pass à 14,99 € pour financer le support post-lancement.
Argument : “Si on vend de l’armure qui change le gameplay, on tue le fun compétitif.”
Et elle a donné un chiffre : 12 % des joueurs ont acheté le pack cosmetic pendant la semaine one.
Le résultat ? Un bon split entre rentabilité et respect du joueur.
Si tu t’intéresses au côté business, lit aussi mon dossier sur le code créateur (/articles/code-createur/) — c’est lié (packaging, revenue share, etc.).
📌 À retenir : dans les petites structures, 12 % de conversion cosmetic peut suffire pour financer 3 mois de support.
H2 : Technique brute — 4 fichiers qui ont sauvé le build
Je voulais du concret technique. Pas du blabla.
Elle m’a montré 4 noms de fichiers (engine_core.cpp, renderer_v2.h, audio_mix.fix, net_patch_1.04.json) et expliqué comment le renderer_v2 a réduit le TTK des ennemis de 0,2 s (perceptible en 120 fps).
Tu vas me dire “c’est trop technique”.
Non. Les lecteurs avancés adorent ces noms. Les novices aiment qu’on leur donne quelque chose à Googler.
Et Google récompense les pages qui documentent des éléments techniques précis.
H2 : Comment j’organise l’interview — check-list en 6 points
Je suis un peu maniaque.
Ma structure tient sur une page.
- Brief de 5 min (rappeler le but).
- 5 questions ouvertes (l’essentiel).
- 3 questions métriques (chiffres).
- 2 relances techniques (noms de fichiers, outils).
- 10 min pour anecdotes/erreurs.
- Conclusion rapide et envoi de la transcription en 24 h.
Ça marche en remote comme en face-à-face.
(En face-à-face, tu prends un café. En remote, tu partages un meme. Même effet.)
H2 : Les pièges à éviter — 3 erreurs que j’ai vues 17 fois
Erreur 1 : demander “Comment s’est passée la dev ?” — réponse bateau.
Erreur 2 : se contenter d’une com PR.
Erreur 3 : oublier d’enregistrer la session en local (cloud qui lâche = fail).
Ce que je fais différemment : je recite la réponse en reformulant.
Ça force le dev à préciser. Et souvent il corrige un chiffre ou ajoute un nom propre. (C’est de l’or.)
💡 Conseil : enregistre en local et sur le cloud. Double sauvegarde = 99,9 % de chances de sauver l’interview.
H2 : Format éditorial — 2 angles qui fonctionnent pour le SEO
Tu veux du trafic pérenne ? Choisis l’angle early-technique ou humain.
Early-technique : focus sur les chiffres, les fichiers, les hacks. (Tu récupères les requêtes “engine_core.cpp bug”.)
Humain : anecdotes, burnouts, décisions RH. (Tu captures les requêtes “interview dev crunch Claire Morel”.)
Je mélange les deux.
Pourquoi ? Parce que tu gagnes les deux types d’audience. Et Google aime les pages qui répondent à des intentions multiples quand c’est fait proprement.
H2 : Transcription et timestamps — 1 format que j’utilise systématiquement
Je fournis la transcription intégrale + timestamps toutes les 2 minutes.
C’est utile pour le lecteur et pour le référencement.
Exemple : 00:02:15 — “On a découvert le leak via un streamer.”
Ça permet à un journaliste, à un podcaster ou à un fan de sauter directement aux passages pertinents.
H2 : Pourquoi publier les chiffres publics aide ton domaine (et ta réputation)
Si tu rendes public 3 métriques clés, tu crées des signaux de confiance.
Les journalistes citent, les autres devs linkent, et Google reconnaît l’autorité.
Ne confonds pas transparence et oversharing.
On ne balance pas les salaires privés ni les contrats. On partage des métriques produit, des dates et des tailles de patch. Ça suffit pour la crédibilité.
H2 : Ce que tu peux reprendre si tu veux interviewer un dev — 7 mini-règles pratiques
- Prépare 5 questions ouvertes.
- Demande 3 chiffres exploitables.
- Nomme au moins 1 fichier ou outil.
- Enregistre en local + cloud.
- Envoie la transcription en 24 h.
- Propose une phrase de relance pour la publication.
- Crée un call-to-action discret (genre “Si tu veux un suivi technique, je peux poster un post-mortem”).
Tu peux reprendre ça tel quel pour ton blog, ta chaîne ou ton podcast. (Oui, même pour un live Twitch.)
H2 : Résultat concret : 2 semaines après la publication
Deux semaines après la mise en ligne, Atelier Rouge a reçu 3 demandes de portage Windows→Linux, 1 proposition d’éditeur et 14 mails de joueurs avec des logs précis.
La preuve que les interviews utiles attirent des actions concrètes. (Pas du trafic vide.)
Bon, je te dis ça parce que j’ai vu les analytics.
Et parce que j’aime quand une interview apporte quelque chose au dev, pas juste du bruit.
FAQ
Q : Combien de temps doit durer une interview pour obtenir des chiffres exploitables ?
R : Vise 45–75 minutes. Sous 30 minutes tu manques les métriques, au-delà de 90 minutes tu perds en focus. Prépare 5 questions ouvertes et 3 demandes de chiffres précis.
Q : Quelles questions exactes poser pour obtenir des données chiffrées ?
R : Demande “Combien d’heures cumulées depuis le prototype ?”, “Taux de crash sur la beta (en %) ?” et “Taille du dernier patch (Mo) et délai de déploiement (jours) ?”. Ces trois questions donnent des facts actionnables.
Q : Comment éviter la com marketing pendant l’interview ?
R : Reformule systématiquement. Si la réponse sonne PR, relance avec “Peux-tu donner un exemple concret ? Un nom de fichier, une date, un chiffre ?” Les relances techniques font tomber le vernis.
Image credits : Atelier Rouge (screenshots fournis par la dev).
Auteur : James LaFleur — ancien dev front, journaliste gaming basé à Lyon. Avatar : /avatar.webp.
