Le vrai coût d'un développeur, c'est le mois d'attente avant de voir quoi que ce soit

Vous recrutez quelqu'un. Vous versez un acompte. Puis, pendant des semaines, rien de concret que vous puissiez tenir en main.

Il y a des appels. Un document de cadrage. Un lien Figma. Un tableau qui se remplit de tickets. Ce que vous n'avez pas, c'est une app que vous pouvez ouvrir sur votre propre téléphone. Cet écart, entre le jour où vous payez et le jour où vous voyez enfin quelque chose de réel qui tourne, c'est là que se loge le plus gros du stress d'un projet logiciel. C'est aussi la partie dont personne ne vous prévient.

Quelques semaines, c'est déjà l'estimation optimiste

Je n'exagère pas l'attente. Les chiffres le confirment. Un développeur qui rejoint un projet met couramment de trois à six mois pour atteindre sa pleine productivité, et de six à douze mois ou plus sur une app complexe. C'est la montée en charge avant que le travail que vous payez n'arrive à plein régime. Même un prestataire aguerri qui démarre vite vous remet rarement un logiciel fonctionnel dans les premières semaines.

Le meilleur conseil du secteur va dans le même sens. Le premier principe du Manifeste Agile est la livraison rapide et continue de logiciel fonctionnel, et même ce principe parle de livrer « avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts ». Donc la référence, ce que toute équipe moderne vise, se compte encore en semaines au mieux.

Pourquoi est-ce si long ? Le cadrage. La mise en place de l'environnement. Les documents de specs. Puis la partie qui grignote discrètement le calendrier : attendre vos retours, vos validations, vos accès et vos contenus, ce qui est de loin la première cause de retard sur les projets freelance. Ajoutez les relais entre un commercial, un chef de projet et la personne qui écrit vraiment le code, et chacun ajoute des heures de latence avant que la moindre ligne ne sorte.

L'attente n'est pas seulement lente, elle est risquée

Un long délai avant de voir un logiciel fonctionnel n'est pas qu'agaçant. Il coûte cher, d'une façon qui n'apparaît pas sur la facture.

On ne peut pas corriger le tir sur quelque chose qu'on ne voit pas. Pendant que vous attendez, de petits désaccords s'accumulent en silence. Tout le monde est occupé, tout le monde suppose que le plan est bon, et les hypothèses se figent. Quand un build finit par arriver, changer de direction veut dire défaire des semaines de travail, donc on le fait rarement. Le conseil des gens qui pilotent ces projets est sans détour : n'autorisez pas des semaines ou des mois de développement sans résultat visible. Exigez de petites étapes que vous pouvez voir.

Je suis d'accord avec ce conseil. Je vais simplement plus loin que la plupart.

Ce que je fais à la place : une app fonctionnelle sur votre appareil ce soir

Je mène le travail sur une seule journée. On échange le matin, je développe dans la journée, et à la fin vous avez une app native installée sur votre propre téléphone, plus le code source. Pas une maquette. Pas un prototype cliquable coincé dans un onglet de navigateur. Une vraie app Swift ou Kotlin qui tourne sur du vrai matériel, et qui est à vous.

C'est possible grâce à trois choses. Dix-sept ans à écrire du code mobile natif, donc je n'apprends pas la plateforme sur votre temps. L'IA dans la boucle, qui supprime une grande partie du travail mécanique lent. Et un lien direct, sans couche d'agence entre vous et le développeur, pour que la conversation du matin devienne du code l'après-midi, sans relais d'e-mails.

Pourquoi cela change la décision que vous prenez

Quand vous recrutez de la manière habituelle, vous engagez de l'argent et des semaines sur la foi d'une promesse et d'un slide. Vous saurez si c'était une bonne idée un mois plus tard.

Quand le premier jour se termine avec une app en main, vous décidez de la suite avec la chose réelle sous les yeux. Si c'est juste, on continue et vous avez déjà une base qui fonctionne. Sinon, vous avez dépensé une journée, pas un mois et un acompte. Votre risque est plafonné à une seule journée de travail, ce qui est à peu près le plus bas possible en logiciel.

C'est tout l'intérêt. Le mois que vous passez normalement à attendre est la partie la plus inconfortable du recrutement d'un développeur, et c'est la partie que je supprime.