Embaucher un·e développeur·se pour réparer du code généré par l'IA : questions d'entretien

Ce qui cloche avec le code généré par l'IA dans des projets réels

Les applications générées par l'IA ont souvent fière allure en démo parce que le « happy path » fonctionne. Le problème commence quand de vrais utilisateurs font de vraies choses : s’inscrire deux fois, réinitialiser un mot de passe, coller une entrée bizarre, ouvrir l’app sur un réseau lent, ou essayer depuis un autre appareil. Beaucoup de prototypes construits rapidement sont assemblés à la va‑vite, donc le premier cas limite peut casser un flux clé.

Les échecs courants sont faciles à repérer quand on sait où regarder. L’authentification est un gros point : la connexion marche en local, puis casse après le déploiement, ou les rôles et sessions se comportent de façon incohérente. Un autre problème classique est l’exposition de secrets, comme des clés API dans le code client ou commitées dans le repo. La logique est souvent fragile aussi : un total de panier est calculé à deux endroits, un webhook s’exécute deux fois, ou les erreurs sont avalées et vous obtenez une corruption silencieuse des données au lieu d’un échec clair.

Signes qui indiquent que le code a besoin d’une vraie réparation (pas seulement quelques ajustements) :

• L’auth et les permissions semblent aléatoires (des utilisateurs voient des choses qu’ils ne devraient pas)
• Des secrets sont codés en dur ou partagés entre environnements
• Un changement dans une zone casse des fonctionnalités sans lien
• La gestion des données est incohérente (doublons, mises à jour manquantes, écritures partielles)
• L’app marche en local mais échoue après déploiement

Ce que vous cherchez n’est pas « quelqu’un pour ajouter des fonctionnalités ». Vous avez besoin de quelqu’un qui diagnostique vite, explique ce qui se passe, et applique des correctifs sûrs sans créer de nouveaux problèmes. Ça implique lire du code inconnu, tracer les requêtes de bout en bout, écrire quelques tests ciblés ou vérifications, et améliorer la structure pour que la prochaine correction soit plus simple.

La rapidité compte, mais la rapidité sans exactitude transforme les prototypes en travail sans fin. Fixez les attentes dès le départ : demandez d’abord un diagnostic initial, puis un plan de réparation avec priorités. Un bon développeur sépare les corrections « arrêter l’hémorragie » (trous de sécurité, auth cassée, perte de données) du travail « rendre plus propre » (refactors, nettoyage). Si vous voulez de la vitesse, soyez clair sur où les approximations sont acceptables et où elles ne le sont pas (sécurité, paiements, données utilisateurs).

Avant l’entretien : définissez le poste dont vous avez vraiment besoin

Si vous voulez embaucher un développeur pour corriger du code généré par l'IA, ne commencez pas par une annonce générique. Ecrivez d’abord ce que « fini » signifie pour votre projet. Sans ça, les entretiens tournent en batailles d’opinions plutôt qu’en décisions claires oui/non.

Définissez « fini » en résultats, pas en ressentis. Pour un repo encombré, « fini » signifie généralement que les flux principaux fonctionnent, que des vérifications de sécurité de base sont en place, et que vous pouvez déployer sans surprises.

Un objectif simple est de lister ce qui doit être vrai à la fin du travail. Restez pragmatique : les parcours utilisateur clés fonctionnent de bout en bout, les chemins à plus haut risque ont au moins un petit filet de sécurité test, les secrets ne sont pas exposés, les étapes de déploiement sont reproductibles (pas de « marche sur ma machine »), et le code est suffisamment lisible pour qu’un autre développeur puisse continuer.

Confirmez ensuite si le travail est vraiment une « réparation » ou un « rebuild ». Les apps générées par l’IA peuvent sembler complètes mais cacher des problèmes profonds (structure emmêlée, état fragile, auth cassée). Décidez ce que vous acceptez : un patch qui stabilise le code actuel, ou une réécriture partielle des parties les plus risquées.

Décidez aussi du type de développeur dont vous avez besoin : quelqu’un à l’aise avec du code qu’il n’a pas écrit. Vous pouvez filtrer ça avant l’entretien en leur demandant de décrire leurs 48 premières heures sur un repo désordonné. Cherchez un plan qui commence par le diagnostic (lancer, reproduire les bugs, lire les logs), puis ajoute de la sécurité (tests, sauvegardes, petits changements), pas de gros refactors dès le jour 1.

Enfin, fixez les attentes sur la communication du risque. Vous voulez quelqu’un qui peut dire : « Je ne suis pas sûr encore. Voici ce que je vais vérifier ensuite, et voici ce qui peut faire changer l’estimation. »

Questions d’entretien qui révèlent leur approche du débogage

Vous n’engagez pas pour l’ingéniosité. Vous engagez pour une méthode reproductible permettant de trouver la cause réelle, même quand le code est désordonné.

Demandez‑leur leurs cinq premières étapes après un rapport de bug critique. Vous écoutez une méthode calme et ordonnée (rassembler les faits, reproduire, réduire la portée), pas « je commencerais à changer des choses ». Les bons candidats mentionnent la confirmation de l’impact, la capture des erreurs exactes, et la vérification des changements récents.

Invites qui exposent leur façon de travailler :

• « Un·e utilisateur·rice dit que le paiement échoue. Quelles sont vos 5 premières étapes, dans l’ordre ? »
• « Comment reproduisez‑vous un bug quand le rapport est vague ? Quelles précisions demandez‑vous ? »
• « Comment isolez‑vous le plus petit cas d’échec, et pourquoi c’est important ? »
• « Sur quoi vous basez‑vous en premier : logs, points d’arrêt, tests, tracing ? Quand changez‑vous d’outil ? »

Après leur réponse, demandez‑leur de raconter un exemple réel. Par exemple : l’app marche en local, mais en production les utilisateurs sont déconnectés aléatoirement. Un bon débogueur parle de comparer les environnements, vérifier les cookies et sessions, chercher des timeouts, et ajouter du logging ciblé avec une hypothèse claire.

La question la plus révélatrice est ce qu’ils font quand ils ne peuvent pas reproduire le bug. Cherchez des réponses comme : améliorer l’observabilité (meilleurs logs, traces), créer un test minimal, réduire le risque avec un garde ou un feature flag, et dresser une courte liste d’hypothèses à confirmer ou éliminer. S’ils disent « je continuerais juste à essayer des choses », c’est un signal d’alarme dans des bases fragiles où un « petit fix » peut casser trois autres flux.

Si vous voulez un test rapide de réalité, demandez‑leur d’expliquer leur approche en langage simple, comme s’ils donnaient un update à un·e fondateur·rice non technique en fin de journée. Des updates clairs correspondent souvent à un débogage discipliné.

Questions qui testent la gestion de l’incertitude et de l’échec

Le code généré par l’IA a tendance à être « faussement sûr ». Vous avez besoin de quelqu’un qui peut admettre une erreur d’hypothèse, changer de direction vite, et laisser le système plus sûr qu’il ne l’a trouvé.

Cette partie de l’entretien ne vise pas des réponses parfaites. Elle vise la réaction quand la réalité ne correspond pas à la première théorie.

Demandez une vraie histoire d’échec (et soyez précis)

Forcez le détail, pas l’histoire soigneusement polie :

• « Parlez‑moi d’un bug que vous avez d’abord mal diagnostiqué. Qu’avez‑vous pensé au départ, et qu’était‑ce réellement ? »
• « Quel signal vous a fait changer d’avis ? »
• « Que faites‑vous en premier pour réduire le risque quand vous êtes encore incertain ? »
• « Comment avez‑vous confirmé la correction, et comment avez‑vous évité de casser quelque chose à côté ? »

S’ils restent vagues, relancez : « Quel a été le plus petit test que vous avez fait pour valider ou invalider votre hypothèse ? »

Un exemple réaliste : la connexion échoue « aléatoirement ». Un candidat faible blâmera « l’auth instable » et testera des bibliothèques. Un bon candidat expliquera comment il a reproduit le problème, repéré une expiration de token ou un décalage d’horloge, et prouvé cela avec un ou deux checks ciblés.

À quoi ressemblent les bonnes réponses

Écoutez des habitudes fiables : timeline (hypothèse, test, résultat, étape suivante), preuve qui a fait changer d’avis, et mesures de confinement (plan de rollback, garde temporaire). Ils préviennent aussi les répétitions avec un petit test, une note de root cause, ou une alerte de monitoring.

Si quelqu’un ne peut pas expliquer une erreur sans rejeter la faute sur les autres, ou prétend « ne jamais se tromper », c’est un signal d’alerte. Déboguer du code désordonné, c’est gérer l’incertitude, et les meilleurs restent calmes et méthodiques.

Habitudes de sécurité : questions qui font ressortir les pratiques réelles

La sécurité est souvent l’endroit où « ça marche en local » devient un vrai risque. Vous voulez des habitudes reproductibles, pas des promesses.

Commencez par l’auth et les sessions. Les apps créées par l’IA mélangent souvent des patterns (cookies, JWTs, localStorage) et laissent des brèches.

Questions qui révèlent vite la pratique réelle :

• « Quand vous ouvrez un nouveau repo, que vérifiez‑vous en premier dans l’auth et la gestion des sessions ? » Écoutez des points concrets : flags de cookie (HttpOnly, Secure, SameSite), durée d’expiration, flux de rafraîchissement, et où les tokens sont stockés.
• « Montrez comment vous trouveriez des secrets exposés et une config dangereuse. » De bonnes réponses incluent le scan des .env committés et des clés dans le repo, plus un plan de rotation et de prévention.
• « Comment empêchez‑vous les injections SQL et les requêtes dangereuses ici ? » Vous voulez entendre des requêtes paramétrées, des patterns ORM sûrs, et la validation d’entrée. Si la réponse est « je nettoie les inputs », demandez comment, précisément.
• « Quelle est votre routine de mise à jour des dépendances sur un projet désordonné ? » Les bonnes réponses couvrent lockfiles, outils d’audit, et un plan de tests après les mises à jour.

Un suivi utile : « Expliquez le compromis entre vitesse et sécurité sur cette correction. » Par exemple, si un prototype stocke des JWTs dans localStorage, un bon ingénieur explique pourquoi passer à des cookies HttpOnly réduit l’impact du XSS, et ce que cela implique côté frontend.

Signaux d’alarme : incapacité à nommer des vérifications concrètes pour les sessions et le stockage des tokens ; traiter la validation d’entrée comme la seule défense contre l’injection SQL ; minimiser le risque des dépendances parce que « c’est juste un prototype » ; ou éviter la rotation des secrets après une fuite.

Comment ils expliquent les compromis en langage simple

Vous n’achetez pas que des compétences techniques. Vous achetez du jugement. Les meilleurs savent dire ce qu’ils font, pourquoi, et ce que ça vous apporte (et ce que ça coûte).

Test simple : demandez‑leur d’expliquer la même décision deux fois, une fois comme à un·e développeur·se et une fois comme à un·e fondateur·rice pressé·e qui veut juste le risque et le coût en clair. S’ils ne peuvent pas changer de registre, vous aurez du mal à prendre des décisions ensemble.

Patch rapide vs refactor propre

Donnez‑leur un bug réel (auth cassée, crash aléatoire, paiements qui échouent) et demandez‑leur de comparer un patch rapide avec une correction en profondeur. Écoutez comment ils décrivent le risque, et s’ils incluent une étape de sécurité comme des tests, du logging, ou un plan de rollback.

Prompts utiles :

• « Si on livre un patch rapide aujourd’hui, qu’est‑ce qui peut casser la semaine suivante ? »
• « Qu’est‑ce qui vous ferait dire : il faut refactorer, pas patcher ? »
• « Comment prouveriez‑vous que la correction fonctionne sans compter sur la chance ? »

Réécrire vs réparer, et comment ils documentent les décisions

Le code généré par l’IA marche souvent jusqu’à ce qu’il rencontre du trafic réel. Demandez comment ils décident de réécrire un module ou de le réparer. Les bons candidats utilisent des signaux comme des frontières floues, des dépendances emmêlées, du code copié‑collé répété, ou un risque de sécurité difficile à contenir.

Demandez un exemple concret : « Si le module profil utilisateur est du spaghetti, que feriez‑vous dans les 48 premières heures ? » Un bon plan est généralement : isoler le module, ajouter quelques tests, refactorer par petites étapes, et surveiller la performance pour ne pas créer de pages lentes ou de surprises de montée en charge.

Enfin, demandez comment ils consignent les décisions de façon compréhensible pour non‑techniques. Cherchez des notes courtes : ce qui a changé, ce qui n’a pas (encore) changé, les risques, et les prochaines étapes.

Un scénario réaliste à dérouler pendant l’entretien

Utilisez une histoire courte et concrète et demandez‑leur de réfléchir à voix haute.

Scénario : après une mise à jour d’un outil IA, les utilisateurs ne peuvent plus se connecter. L’app affiche « session invalide » même avec le bon mot de passe. Ça marchait hier. Maintenant les tickets de support arrivent en masse.

D’abord, écoutez les questions qu’ils posent avant de toucher au code. Les bons candidats veulent savoir : qu’est‑ce qui a changé (déploiement, vars d’environnement, mise à jour de dépendance), est‑ce que ça affecte tous les utilisateurs ou un sous‑ensemble, y a‑t‑il des logs ou traces, quelle méthode d’auth utilisez‑vous (cookies, JWT, OAuth), et est‑ce que des secrets ou clés ont été tournés. Bonus s’ils s’inquiètent du risque : « Les utilisateurs sont-ils uniquement verrouillés dehors, ou des sessions sont‑elles acceptées incorrectement ? »

Ensuite, demandez‑leur de cadrer leur approche dans le temps. Le plan doit ressembler à une checklist, pas à des suppositions :

• Première heure : reproduire le bug, capturer une requête/réponse échouée, scanner les diffs récents, confirmer la config (domaine du cookie, CORS, URL de callback, store de session).
• Premier jour : tracer le flux de connexion complet, ajouter du logging temporaire autour de la création et validation des sessions, écrire un petit test qui prouve l’échec.
• Une fois stable : refactorer les parties fragiles, supprimer les couplages cachés, ajouter du monitoring, documenter les changements pour éviter la répétition.

Demandez ensuite comment ils confirment la correction. De bonnes réponses incluent une étape reproductible, des tests pour les cas de succès et d’échec, et un plan de rollback. Ils doivent aussi mentionner des mesures pour prévenir la répétition (figer des versions, contrôles de config plus sûrs, règles de revue basique).

Enfin, poussez sur les compromis : que livrer maintenant vs programmer plus tard ? Vous voulez quelqu’un qui protège les utilisateurs aujourd’hui sans vous enfouir dans une dette technique insurmontable.

Pièges courants lors d’un entretien pour réparer du code en désordre

Les plus grosses erreurs d’entretien surviennent quand la conversation reste abstraite. Vous voulez des détails : ce qu’ils regardent d’abord, ce qu’ils mesurent, et ce qu’ils font quand ils se trompent.

Un piège est de poser des questions qui récompensent la confiance plutôt que la clarté. Si vous demandez « Pouvez‑vous nettoyer ça ? » vous obtiendrez un « oui » de presque tout le monde. Au lieu de ça, insistez sur le spécifique : quels signaux leur diraient que le bug vient des données, de l’auth, ou de l’état, et quelles preuves ils collecteraient avant de toucher au code.

Autre erreur fréquente : trop se focaliser sur les frameworks. Un candidat qui ne parle que de réécrire dans la dernière stack peut éviter le vrai travail : lire du code étrange, tracer des requêtes, et réduire le risque.

Signes d’alarme :

• Leur plan de débogage se résume à « ajouter des console.logs » (sans repro, réduction d’entrée, logs et traces).
• Ils repoussent les tests à plus tard et ne parlent pas d’un filet de sécurité avant les refactors.
• Ils donnent un calendrier ferme sans demander à voir le repo, les configs et le setup de déploiement.
• Ils refusent d’expliquer leurs décisions en langage simple, ou se vexent aux questions « pourquoi ».

Les timelines sont un piège à part. Les bons ingénieurs donnent des plages et un plan, pas une promesse ferme. « Jour 1 : reproduire et cartographier le flux. Jour 2 : corriger les causes principales et ajouter des tests. Puis réévaluer » est plus crédible qu’un délai garanti sans revue de code.

Checklist rapide : signes que vous avez trouvé la bonne personne

Après une courte revue, un bon candidat peut vous dire ce qu’il regarde et pourquoi ça échoue. Il n’a pas besoin d’une certitude totale, mais il doit pouvoir résumer la base de code en termes simples : ce que l’app fait, où sont les flux principaux (login, paiements, uploads, admin), et ce qui semble anormal (vars manquantes, modèle de données confus, logique dupliquée).

Ils ne se lanceront pas immédiatement dans des réécritures. Le meilleur schéma est : « d’abord un audit rapide, puis une liste de correctifs priorisés ». Cette liste doit être classée par impact et risque, pas par ce qui est amusant à bidouiller.

Écoutez des habitudes de production, pas des promesses vagues. Ils doivent naturellement mentionner des tests pour les chemins cassés, un environnement de staging, un plan de rollback, et du monitoring basique (même des logs et alertes simples). Ils doivent parler de comment prouver que la correction a marché, pas seulement de l’implémenter.

La sécurité est un autre révélateur rapide. Un bon candidat repère les risques sans que vous les lui souffliez : secrets exposés, contrôles d’auth faibles, construction SQL dangereuse, validation d’entrée manquante, ou CORS trop permissif.

Demandez aussi comment ils organiseront le travail semaine après semaine. Vous voulez des points de contrôle clairs et des livrables compréhensibles : une courte liste des problèmes principaux avec leur sévérité, ce qui a été livré, ce qui suit, et ce qui bloque.

Étapes suivantes : lancez un petit essai et fixez un plan de réparation clair

Ne plongez pas directement dans une grosse réécriture. Avec du code IA désordonné, vous en apprenez plus avec un petit essai payé qu’avec une heure de discussion supplémentaire. L’objectif est de voir comment ils pensent, communiquent, et s’ils laissent le code plus sûr.

Gardez l’essai petit mais réel : un bug visible par les utilisateurs, une correction de sécurité, et un test simple pour verrouiller le changement. Par exemple : « la connexion échoue parfois », « retirez un secret exposé du repo et faites‑le tourner », et « ajoutez un test basique pour la connexion ». Un périmètre serré vous permet de juger les résultats en un ou deux jours.

Avant de commencer, accordez‑vous sur ce que « fini » signifie et ce que vous recevrez. Vous devriez obtenir une courte explication de ce qui a changé et pourquoi, des notes sur les mises à jour de config ou d’environnement, et un plan de déploiement simple incluant comment vérifier et comment revenir en arrière.

Si vous n’avez pas le temps d’évaluer longuement les candidats, une approche audit‑first peut quand même faire avancer les choses. FixMyMess (fixmymess.ai) se concentre sur le diagnostic et la réparation d’apps générées par l’IA depuis des outils comme Lovable, Bolt, v0, Cursor et Replit, et commence par un audit de code gratuit pour que vous puissiez voir les problèmes concrets et les priorités avant de vous engager dans une réécriture.