Ce que ton développeur ne te dit pas (et que tu devrais lui demander)

Tu fais confiance à ton dev, et c'est normal

Tu as trouvé un développeur. Freelance, agence, ou interne. Il est compétent, réactif, il livre ce que tu demandes. Tu lui fais confiance. Et c'est tout à fait normal.

Mais la confiance ne remplace pas la visibilité.

J'ai vu trop de projets où le PM découvre après six mois que l'application n'a aucun test automatisé. Que la base de données n'a jamais été sauvegardée. Que le code n'est documenté nulle part et que personne d'autre que le développeur actuel ne peut le comprendre. Six mois de développement, des dizaines de milliers de francs investis, et un jour le dev n'est plus disponible. Ou le projet doit évoluer. Et là, c'est la douche froide.

Ce n'est pas une question de mauvaise foi. C'est une question de communication. Et dans la relation client/développeur, il y a des choses qui ne remontent presque jamais spontanément.

"Tout avance bien"

C'est probablement la phrase la plus dangereuse dans un projet tech.

Quand ton développeur te dit que tout avance bien, dans la majorité des cas, c'est vrai. Mais parfois, ça veut dire autre chose. Ça veut dire : "J'ai un problème, mais je pense pouvoir le résoudre." Ou : "Il y a de la dette technique qui s'accumule, mais ce n'est pas le moment d'en parler." Ou encore : "Je suis bloqué depuis deux jours sur un truc, mais je ne veux pas avoir l'air incompétent."

Les développeurs ne cachent pas les problèmes par malveillance. Ils le font par habitude, par optimisme, ou parce qu'ils estiment que le client ne comprendrait pas les détails techniques. Et honnêtement, ils ont souvent raison sur ce dernier point. Mais ça ne veut pas dire que tu dois rester dans le flou.

Le vrai enjeu, ce n'est pas de comprendre chaque ligne de code. C'est de poser les bonnes questions pour avoir une visibilité réelle sur l'état de ton projet.

Les questions que tu devrais poser régulièrement

Ces questions ne nécessitent aucune compétence technique. Elles nécessitent juste le réflexe de les poser. Et les réponses, même si tu ne comprends pas tous les détails, vont te donner des signaux très clairs sur la santé de ton projet.

"Est-ce que le projet a des tests automatisés ? Combien ?"

Un projet sans tests, c'est un projet où chaque modification est un pari. Tu changes un truc ici, ça casse là-bas, et personne ne s'en rend compte avant qu'un utilisateur signale le bug en production. Les tests automatisés, c'est le filet de sécurité. Si ton dev te dit qu'il n'y en a pas, ou qu'il n'a "pas eu le temps", c'est un signal d'alarme. Pas parce que c'est grave aujourd'hui, mais parce que ça le deviendra.

"Si tu disparais demain, un autre dev peut reprendre en combien de temps ?"

Cette question met souvent mal à l'aise, et c'est exactement pour ça qu'il faut la poser. La réponse honnête, c'est souvent "quelques semaines". Si c'est "quelques jours", tu es dans une bonne situation. Si c'est "quelques mois" ou un silence gêné, tu as un problème de dépendance qui va te coûter cher tôt ou tard.

"Quelle est la dette technique actuelle ?"

La dette technique, c'est l'ensemble des compromis qu'on a faits pour aller vite. Tout projet en a. Ce n'est pas un problème en soi. Le problème, c'est quand personne ne la mesure et que personne ne la rembourse. Demande à ton dev de te la décrire en termes simples. Si la réponse est "il n'y en a pas", soit ton dev est un génie, soit il ne veut pas en parler.

"Est-ce que le code est versionné et déployable automatiquement ?"

Le versionnage (Git), c'est le minimum vital. Ça permet de revenir en arrière si quelque chose casse, de travailler à plusieurs sur le même code, et d'avoir un historique de toutes les modifications. Le déploiement automatique (CI/CD), c'est la capacité à mettre en ligne une nouvelle version en quelques minutes, de manière fiable et reproductible. Si ton dev déploie en faisant du copier-coller sur un serveur, tu es en 2010.

"Qu'est-ce qui te bloque ou te ralentit en ce moment ?"

Cette question est un cadeau que tu fais à ton développeur. Elle lui donne la permission de parler des vrais problèmes. Peut-être qu'il galère avec une API externe mal documentée. Peut-être que les spécifications ne sont pas claires et qu'il improvise. Peut-être qu'il passe 30% de son temps à contourner une décision technique prise il y a six mois. Tu ne peux pas l'aider si tu ne sais pas.

"Est-ce que les données utilisateurs sont sécurisées ?"

C'est la question que personne ne pose jusqu'au jour où il y a une fuite. Les mots de passe sont hashés ? Les données sensibles sont chiffrées ? Les accès API sont protégés ? Les backups sont en place ? Si ton dev ne peut pas répondre clairement à ces questions, tu as un problème. Et en Suisse, avec la LPD (la loi sur la protection des données), ce problème est aussi juridique.

"Quelle est la chose que tu ferais différemment si tu recommençais ?"

Ma question préférée. Parce que la réponse révèle tout. Si ton dev a une réponse précise et réfléchie, ça veut dire qu'il a du recul sur son travail, qu'il voit les compromis, et qu'il est capable d'autocritique. C'est le signe d'un bon professionnel. Si la réponse est "rien, tout est parfait", méfie-toi. Aucun projet n'est parfait. Celui qui prétend le contraire, soit il ne voit pas les problèmes, soit il ne veut pas les voir.

Les signaux d'alerte que tu peux repérer sans coder

Tu n'as pas besoin de lire du code pour sentir qu'un projet va dans le mur. Il y a des signes observables, concrets, qui ne trompent pas.

Les estimations sont toujours dépassées. Pas de temps en temps, systématiquement. "Ça prendra deux jours" se transforme en une semaine. "C'est presque fini" dure trois semaines. Ce n'est pas forcément de l'incompétence. C'est souvent le symptôme d'un code devenu trop complexe à faire évoluer. Chaque modification prend plus de temps parce que le projet accumule de la dette technique non gérée.

Les "petites modifs" prennent des jours. Quand changer la couleur d'un bouton ou ajouter un champ dans un formulaire devient une opération de deux jours, c'est que l'architecture ne tient plus. Un projet bien structuré permet de faire des changements simples simplement.

Ton dev a peur de toucher certaines parties du code. "Ça marche, on n'y touche pas." Cette phrase devrait te faire dresser les oreilles. Un code qu'on n'ose pas modifier, c'est un code qu'on ne comprend plus. Et un code qu'on ne comprend plus, c'est une bombe à retardement.

Il n'y a pas de démo régulière. Si tu ne vois le produit que quand c'est "terminé", tu découvres les problèmes trop tard. Un bon rythme, c'est une démo toutes les une à deux semaines, même si c'est incomplet. Ça permet de corriger le tir avant que le projet ne parte dans la mauvaise direction.

Tu ne peux pas accéder au code source. C'est le red flag ultime. Le code, c'est ce que tu paies. Tu dois y avoir accès en permanence, sur un dépôt que tu contrôles. Si ton prestataire refuse, ou s'il te dit que "c'est sur son ordinateur", tu as un problème de propriété intellectuelle en plus d'un problème technique.

Comment devenir un meilleur client tech

Poser ces questions, ce n'est pas du micro-management. C'est l'inverse. C'est donner à ton développeur le cadre pour être transparent, pour remonter les problèmes tôt, et pour faire les bons choix techniques sans avoir à les cacher.

Les meilleurs projets sur lesquels j'ai travaillé, c'était avec des clients qui posaient des questions, qui acceptaient d'entendre les mauvaises nouvelles tôt, et qui investissaient dans la qualité même quand ça ne se voyait pas à l'écran. Des clients qui comprenaient que la sécurité, les tests et la documentation ne sont pas du temps perdu, mais du temps investi.

Tu n'as pas besoin de devenir technique. Tu as besoin de devenir exigeant sur la transparence. De demander des preuves, pas des promesses. De préférer un dev qui te dit "c'est plus compliqué que prévu, voilà pourquoi" plutôt qu'un dev qui te dit "tout va bien" pendant six mois avant de t'annoncer que le projet doit être refait.

Et si ton dev, c'est une IA ?

Si tu as lu mon article précédent sur les projets vibe codés, tu sais que de plus en plus de gens construisent leurs produits avec l'IA. Et tout ce que je viens de dire s'applique aussi dans ce cas. Peut-être même encore plus.

Et si ton dev c'est Claude, ChatGPT ou Gemini, n'hésite pas à lui poser ces questions-là. Tu vas peut-être découvrir des choses intéressantes. Demande-lui s'il y a des tests. Demande-lui quelle est la dette technique. Demande-lui ce qu'il ferait différemment s'il recommençait. Les réponses risquent de te surprendre.

Parce que le problème n'est jamais l'outil. Le problème, c'est de ne pas poser les bonnes questions.

Et si les réponses te laissent perplexe, qu'elles viennent d'un humain ou d'une IA, un regard extérieur de quelques heures peut faire toute la différence.