FAQ
Les questions qu'on me pose souvent.
La méthode
Pourquoi un compte-rendu chaque jour ? Une réunion hebdo, ce n'est pas suffisant ?
Un point hebdo vous dit ce qui s'est passé. Un compte-rendu quotidien vous permet de réagir le jour-même. Si je découvre un blocage le mardi, vous pouvez trancher le mercredi — pas le lundi suivant. Sur un projet financé, perdre une semaine à attendre la prochaine réunion, c'est cher. Le format est volontairement léger : un message factuel le soir, lu en 30 secondes, archivé. Pas une présentation soignée à préparer.
Vous travaillez à distance — comment je sais que vous serez là quand j'en aurai besoin ?
Je suis présent tous les jours en heures ouvrées. Le compte-rendu quotidien le matérialise — vous voyez chaque soir ce qui a été fait. Sur les canaux de communication, j'utilise les vôtres (Slack, mail, Teams, etc.), pas un portail dédié à apprendre.
Et si vous êtes malade, en vacances, ou débordé ?
Je suis un humain, pas une équipe — je ne promets pas une disponibilité 24/7. Pour les vacances, je préviens à l'avance et on cale les jalons en conséquence. En cas d'imprévu long, je connais quelques freelances seniors de confiance que je peux éventuellement vous recommander, sans intermédiation.
La collaboration
Un forfait MVP en 20 jours, c'est crédible ou c'est du marketing ?
C'est crédible si le scope est précis — c'est pourquoi on le définit ensemble avant de signer. Le format devient réaliste aujourd'hui parce que l'IA accélère certaines tâches répétitives : boilerplate, tests, refacto local. Mais ce n'est pas magique. On ne livre pas une plateforme bancaire en 15 jours. Sur un MVP, on livre les fonctionnalités cœur, déployées, testées, utilisables.
Tu peux prendre un chantier sans brief exhaustif ?
Oui, à condition que le scope soit délimité. Je ne travaille pas bien dans le flou total — pas parce que je ne suis pas autonome, mais parce que le flou produit du code qui part dans tous les sens. Si le brief est incomplet, je pose les questions qui manquent avant de démarrer, pas au milieu.
Je ne connais rien à la tech — est-ce que c'est un problème ?
Non. Ce n'est pas votre métier, c'est le mien. Ce que j'attends de vous, c'est que vous connaissiez votre marché, vos utilisateurs, vos contraintes business. Je m'occupe de traduire ça en produit. Si une décision technique vous concerne, je vous l'explique en termes clairs avant de la prendre.
Tu peux coordonner une équipe, pas seulement coder ?
Oui. Chez Coton, j'ai piloté des équipes de freelances sur des missions clients — sélection des profils, répartition du travail, points de synchronisation, tests techniques de recrutement. Sur le projet Ublo, j'ai coordonné une équipe de 4 développeurs juniors : cadrage des chantiers, revues de PR, accompagnement technique quotidien. Si vous avez besoin de quelqu'un qui code et structure le travail autour d'une équipe réduite, c'est quelque chose que je fais.
Vous pouvez m'aider à recruter mon équipe tech ?
En partie. Je ne chasse pas les profils — c'est le travail d'un recruteur. Mais je peux créer les tests techniques, évaluer les candidats, et conduire les entretiens techniques. C'est un rôle que j'ai tenu chez Coton pour recruter les freelances du collectif, et qu'on proposait aussi à nos clients. Si vous avez des candidats à évaluer, je vous donne une lecture structurée.
Le profil
Pourquoi vous, plutôt qu'une agence ou un autre freelance ?
Je n'ai pas la prétention d'être le meilleur. J'ai 10 ans de dev TypeScript dans les pattes, 6 ans à co-fonder le collectif Coton — soit des dizaines de missions freelance vues de l'intérieur, réussies et plantées. Les méthodes que j'applique (compte-rendu quotidien, devis borné au démarrage) sont issues de ce que j'ai vu marcher chez les plus solides du collectif. C'est ça que je propose.
Qu'est-ce que tu ne feras pas ?
Je ne joue pas au héros. Je ne prends pas de décisions d'architecture qui engagent le long terme sans vous en parler. Je ne code pas vite pour avoir l'air productif — je code proprement pour que ça tienne.
La technique
Comment tu t'intègres dans une codebase existante ?
Je lis avant d'écrire. Je commence par comprendre les conventions du projet, les patterns déjà en place, les endroits fragiles. Je ne refactore pas tout dès la première semaine. Si je vois quelque chose qui mérite d'être discuté, je le pose à l'écrit — dans le compte-rendu ou directement dans la PR — sans imposer.
Vous pouvez me conseiller sur les choix de stack ou d'architecture ?
Oui, c'est même une partie importante de ce que je fais. Pas pour vous vendre une techno exotique, mais pour vous aider à choisir ce qui correspond à votre contexte : votre budget, vos ambitions, vos contraintes de recrutement futur. Je vous donne mon avis avec les raisons, vous décidez.
L'IA et le code
Vous codez avec l'IA, donc c'est juste du code généré que je paye au prix fort ?
L'IA est un outil. Ce que vous payez, c'est le cadrage de ce qui doit être codé, le choix de l'architecture, le contrôle de ce qui sort, la prise de décision sur les compromis, et la responsabilité de garantir que ça tient dans 18 mois. Du code IA mal piloté crée de la dette technique invisible — c'est exactement ce que mon travail consiste à éviter. Le code que vous recevez est celui que j'aurais écrit, en plus vite.
Premier échange · 30 à 45 minutes · Sans engagement