Imaginons un dépôt de logiciel personnel dont la numérotation continue des Issues et Pull Requests GitHub approche quatre chiffres.
La réaction immédiate est tentante :
« Une seule personne a presque réalisé mille tâches de développement ? »
Presque, mais cette conversion est incorrecte. Pour la numérotation, GitHub considère chaque Pull Request comme une forme d’Issue, et les numéros d’Issues et de Pull Requests ne se chevauchent pas dans un même dépôt. Approcher le numéro 1000 ne signifie donc pas avoir terminé 1000 Pull Requests.[1]
La question vraiment intéressante reste entière :
Si une personne devait effectuer presque manuellement, sans IA, ce volume de modifications, contrôles, réparations, publications et opérations, combien cela coûterait-il et le modèle serait-il rentable ?
C’est une question centrale pour comprendre l’économie du développement solo assisté par IA.
1. Le numéro GitHub n’est pas un compteur de répétitions à la salle de sport
La numérotation d’un dépôt n’est pas un indicateur de charge de travail.
Un développeur peut mettre 2000 lignes de changements dans un seul Pull Request. Un autre peut en ouvrir un pour modifier une seule ligne de CSS. Les Issues occupent le même espace de numérotation : bugs, notes de conception, demandes de fonctionnalités, investigations et tâches opérationnelles.
Donc :
un numéro proche de 1000 ne signifie pas le travail de 1000 personnes.
Cela ne signifie pas non plus :
presque 1000 fonctionnalités terminées.
Le numéro ressemble davantage au compteur d’un portillon qu’à une balance.
Cependant, si beaucoup de petits changements se sont accumulés en peu de temps, l’historique révèle quelque chose d’utile : la boucle conception → implémentation → vérification → réparation a été exécutée de nombreuses fois.
Pour estimer le coût humain, la variable importante n’est pas le numéro lui-même, mais le temps moyen consommé par chaque boucle substantielle.
2. Le coût humain est particulièrement facile à sous-estimer quand chaque tâche paraît minuscule
Un rapport publié en septembre 2026 à partir d’offres de missions pour ingénieurs freelances au Japon situait la moyenne mensuelle d’août 2026 à 789 000 yens.[2]
Ce n’est ni le salaire de tous les développeurs ni le taux horaire d’une personne particulière. C’est une moyenne du marché des missions publiées.
Mais cela peut servir de repère de coût de remplacement : combien coûterait une capacité d’ingénierie professionnelle comparable si elle était achetée à l’extérieur ?
À 160 heures par mois, cela représente environ 4930 yens par heure.
Supposons maintenant 1000 unités de changement substantielles. Il s’agit d’un exemple hypothétique, volontairement distinct du numéro GitHub #1000.
| Temps moyen par changement | Temps total | Mois-personnes à 160 h/mois | Coût à 789 000 yens/mois |
|---|---|---|---|
| 15 min | 250 h | 1,56 | env. 1,23 M¥ |
| 30 min | 500 h | 3,13 | env. 2,47 M¥ |
| 45 min | 750 h | 4,69 | env. 3,70 M¥ |
| 1 h | 1000 h | 6,25 | env. 4,93 M¥ |
| 2 h | 2000 h | 12,5 | env. 9,86 M¥ |
| 3 h | 3000 h | 18,75 | env. 14,79 M¥ |
| 4 h | 4000 h | 25 | env. 19,73 M¥ |
Même 1000 changements de seulement 15 minutes représentent 250 heures.
« Chaque tâche est petite » ne signifie pas « le total est petit ».
Les petites tâches comportent aussi des coûts fixes : recherche, création de branche, revue, tests, fusion, vérification du déploiement et réflexion sur le retour arrière.
Si une seule personne fait tout manuellement, sa carte de visite finit par devenir un dépliant : rédacteur, traducteur, frontend, backend, QA, infrastructure et rédacteur en chef.
3. « Je l’ai fait moi-même, donc le coût du travail est nul » peut être vrai en trésorerie et faux en comparaison économique
Un site personnel peut dépenser 1000 yens par mois pour l’hébergement et gagner 5000 yens en publicité.
En trésorerie, le surplus est bien de 4000 yens.
Mais si le propriétaire y consacre 50 heures par mois, la comparaison en tant qu’activité économique nécessite une seconde lecture.
Il faut au moins distinguer :
Profit de trésorerie = revenus − dépenses monétaires
Profit ajusté du travail = revenus − dépenses monétaires − heures du propriétaire × valeur horaire de remplacement choisie
Pour un loisir, attribuer une valeur nulle à son propre temps peut être parfaitement raisonnable. On ne dit généralement pas que jouer 50 heures à un jeu vidéo crée une perte de main-d’œuvre.
Le problème apparaît seulement quand la comptabilité du loisir est présentée comme preuve de rentabilité commerciale.
L’apprentissage, le plaisir, la réputation et la satisfaction de construire sont des retours réels. Ils ne sont simplement pas identiques au profit d’une entreprise.
Dans une comparaison économique, le temps ne disparaît pas parce qu’aucune facture n’a été émise.
4. La publicité peut exiger un dénominateur étonnamment grand
Une formule simplifiée est :
Revenus publicitaires = pages vues ÷ 1000 × RPM effectif
Le RPM varie fortement selon le pays, l’appareil, le format, la saison, le sujet, l’audience et la configuration publicitaire.
Au lieu de prétendre qu’il existe un RPM universel, utilisons uniquement des valeurs hypothétiques pour voir l’ordre de grandeur.
S’il fallait récupérer 789 000 yens par mois grâce à la publicité seule :
| RPM effectif hypothétique | PV nécessaires pour 789 000 yens/mois |
|---|---|
| 100 yens | env. 7,89 millions |
| 300 yens | env. 2,63 millions |
| 500 yens | env. 1,58 million |
| 800 yens | env. 0,99 million |
Ce n’est pas une prévision de revenus pour un site particulier.
Le tableau montre que si le travail manuel est valorisé au coût professionnel de remplacement, récupérer tout ce coût uniquement par la publicité peut exiger énormément de trafic.
C’est pourquoi de nombreux sites manuels combinent publicité, affiliation, vente de produits, acquisition de clients, abonnements, dons, valeur de marque ou valeur de loisir.
5. L’IA change bien plus que la vitesse d’écriture
Réduire la valeur de l’IA à « elle écrit un article en 30 secondes » rate une grande partie de l’économie.
Exploiter une publication web comprend de nombreux travaux périphériques :
- trouver des sujets,
- rechercher,
- rédiger,
- vérifier les faits,
- modifier le code,
- tester,
- localiser,
- publier,
- vérifier le résultat réel en production,
- réparer les incidents,
- distribuer sur les réseaux et par newsletter,
- mesurer puis améliorer.
Avec une exploitation manuelle, chaque processus supplémentaire tend à augmenter le coût variable du travail.
Avec l’IA et l’automatisation, le coût initial de construction du système peut être plus élevé, mais le coût marginal du deuxième, du dixième et du centième élément peut diminuer.
Ce n’est pas seulement « le rédacteur est plus rapide ».
C’est plutôt :
une personne peut posséder le système d’exploitation d’une petite rédaction et d’une petite équipe d’ingénierie.
L’humain ne disparaît pas.
Son rôle se déplace vers les entrées, les décisions, les spécifications, les critères de qualité, les exceptions et la gouvernance.
Il passe de la fabrication manuelle de chaque artefact à la conception de l’usine et à l’édition de sa production.
6. L’IA n’est pas un turbo magique qui accélère toujours le développement
Les résultats de recherche sont intéressants précisément parce qu’ils ne vont pas tous dans le même sens.
Une étude contrôlée publiée en 2023 a trouvé que les participants disposant de GitHub Copilot terminaient une tâche précise de serveur HTTP JavaScript 55,8 % plus vite que le groupe témoin.[3]
À l’inverse, un essai randomisé de METR en 2025 a trouvé que 16 développeurs open source expérimentés, travaillant dans des dépôts matures qu’ils connaissaient depuis des années, prenaient en moyenne 19 % plus de temps lorsque les outils d’IA du début 2025 étaient autorisés.[4]
En février 2026, METR a expliqué que son expérience suivante était devenue difficile à interpréter. Davantage de développeurs refusaient de participer s’ils devaient travailler sans IA, et le temps de travail devenait plus difficile à mesurer chez ceux qui utilisaient plusieurs agents en parallèle. Il est plausible que les outils plus récents accélèrent davantage que ceux du début 2025, mais les nouvelles données ne permettent pas d’affirmer un pourcentage précis avec confiance à cause des biais de sélection et des problèmes de mesure.[5]
La conclusion n’est donc pas :
l’IA rend toujours le développement 55 % plus rapide.
Ni :
l’IA ralentit les experts de 19 %.
L’effet dépend de la tâche, de la familiarité avec le code, du flux d’agents, de la charge de revue, du parallélisme et de l’environnement de test.
L’IA peut produire de bons résultats très vite. Un mauvais système peut aussi produire des bugs très vite.
La mesure pertinente est celle observée dans le flux réel du projet.
7. Un site manuel ne perd pas automatiquement
Un système très automatisé avec IA n’est pas garanti d’être plus rentable qu’un site artisanal.
La production manuelle peut être rationnelle lorsque :
- seulement quelques contenus sont publiés chaque mois,
- l’écriture personnelle de l’expert est elle-même le produit,
- un seul article vend un produit ou service de forte valeur,
- la localisation et la distribution massive sont inutiles,
- les mises à jour sont rares,
- le propriétaire apprécie la production comme loisir,
- ou le coût de l’automatisation dépasserait le travail économisé.
L’automatisation devient plus intéressante lorsque :
- le même processus se répète constamment,
- plusieurs langues sont maintenues,
- le stock de contenu augmente,
- chaque publication exige QA et vérification réelle,
- les canaux de distribution se multiplient,
- et les humains répètent sans cesse les mêmes contrôles.
C’est fondamentalement un problème de coûts fixes et de coûts variables.
L’usine IA peut être chère au départ. L’atelier manuel peut être cher par unité.
Et il faut garder une chose en tête : une magnifique usine entièrement automatisée sans aucun lecteur n’est pas le futur des médias. C’est un entrepôt extraordinairement sophistiqué.
8. Pour comprendre la rentabilité d’un site manuel sans IA, quelques chiffres suffisent
Il n’est pas nécessaire de juger la personne.
Pour comparer les systèmes, il suffit de connaître :
- Heures du propriétaire par mois
- PV ou utilisateurs uniques mensuels
- Revenus et dépenses monétaires mensuels
- Nombre d’articles et nouveaux articles par mois
- Nombre de langues
- Années d’exploitation et heures approximatives de construction initiale
On peut ensuite calculer :
Profit de trésorerie = revenus − dépenses monétaires
Rendement de trésorerie horaire du propriétaire = profit de trésorerie ÷ heures
Profit ajusté du travail = profit de trésorerie − heures × valeur horaire de comparaison
Coût marginal par article = travail et dépenses supplémentaires de rédaction + traduction + QA + publication + distribution
Le dernier indicateur est particulièrement important.
Le fait d’avoir dépensé 1000 heures dans le passé explique moins l’avenir que le nombre d’heures nécessaires aujourd’hui pour publier l’article suivant.
9. Le vrai avantage de l’IA en développement solo n’est pas le volume, mais la répétabilité
Générer une montagne de fichiers en une nuit n’est plus la partie la plus difficile.
Le difficile est de construire un système où :
- les mêmes critères de qualité s’appliquent la prochaine fois,
- seul le périmètre qui a échoué doit être repris,
- les doubles publications sont empêchées,
- la révision courante est identifiable,
- le résultat réel en production est vérifié,
- un canal bloqué ne gèle pas les travaux indépendants,
- l’authentification qui exige réellement un humain revient à un humain,
- et l’historique reste auditable.
Ce n’est pas simplement du volume de génération.
C’est un actif opérationnel.
Un site manuel peut construire le même type d’actif grâce à des procédures, modèles, CMS, sauvegardes et listes de contrôle.
La différence à l’ère de l’IA est qu’une seule personne peut désormais construire ces couches opérationnelles avec une profondeur inhabituelle.
10. Conclusion : la question intéressante n’est pas « a-t-on atteint 1000 ? », mais « combien coûte l’unité suivante ? »
Un numéro séquentiel d’Issues et Pull Requests proche de quatre chiffres est visuellement impressionnant.
Il ne faut pas en faire un score de productivité.
Les chiffres plus utiles sont :
les heures humaines, le coût par changement, le coût marginal par article, le taux de reprise avant publication, la production par heure du propriétaire, et le profit ajusté du travail par rapport aux revenus.
Un site manuel peut parfaitement être rentable.
Un site avec IA peut parfaitement perdre de l’argent.
Mais les courbes de coûts diffèrent fortement entre un modèle où des humains répètent manuellement rédaction, traduction, développement, QA, publication, surveillance et distribution, et un modèle qui investit d’abord pour systématiser ces étapes puis réduire le coût marginal.
La proximité du numéro 1000 est intéressante non parce qu’il s’agit d’une médaille.
La vraie question est :
parmi toutes ces boucles d’essai et de réparation, combien sont devenues des mécanismes qui évitent à l’humain de refaire le même travail la prochaine fois ?
C’est là que l’économie du développement solo assisté par IA devient réellement différente.
Références (5)
- GitHub Docs — Issue event types / REST API. GitHub states that every pull request is an issue, but not every issue is a pull request, and that issue and pull-request numbers do not overlap within a repository docs.github.com
- En Japan / Freelance Start, 2026-09-03. August 2026 freelance-engineer listings averaged ¥789,000 per month; 445,327 listings were included at month end. This is a marketplace listing statistic, not a universal salary or an observed cost for any person discussed in this article prtimes.jp
- Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. (2023). “The Impact of AI on Developer Productivity: Evidence from GitHub Copilot.” In a controlled JavaScript HTTP-server task, the treatment group completed the task 55.8% faster arxiv.org
- Becker, J., Rush, N., Barnes, B., & Rein, D. / METR (2025-07-10). “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity.” Sixteen experienced developers completed 246 tasks in mature repositories; allowing early-2025 AI tools increased completion time by 19% on average in this study metr.org
- METR (2026-02-24). “We are Changing our Developer Productivity Experiment Design.” METR reports that later productivity experiments suffered from participant-selection and time-measurement problems, especially as developers became reluctant to work without AI and used multiple agents in parallel; the newer data are weak evidence for the size of current speedup metr.org
