Une modification logicielle assez importante a été confiée à un agent IA.
Cela ressemblait à une tâche de quelques dizaines de minutes. Pourtant, GitHub a continué d’accumuler commits, tests, changements d’intégration et corrections. Plusieurs heures plus tard, le vrai code changeait encore.
Pendant ce temps, l’humain a terminé des tâches dans le monde réel — jusqu’à finir un déménagement complet.
Le déménagement s’est terminé avant le refactoring.
La scène paraît déjà très futuriste.
Et l’interface n’était qu’un smartphone. La personne qui donne les instructions n’a pas besoin de maîtriser chaque module TypeScript, détail CI/CD ou règle d’apprentissage du graphe. Elle peut décrire en langage naturel l’objectif, les invariants, les autorisations, les changements interdits et les critères de fin; l’agent lit le dépôt, conçoit, code, ajoute des tests, ouvre des PR et intègre les changements.
Est-ce « devenir ingénieur senior avec seulement un téléphone » ?
Pas exactement. Mais nous en sommes beaucoup plus près que ne le suggérait l’ancien modèle du développement logiciel.
1. Le smartphone ne fait pas lui-même le calcul de niveau senior
Le téléphone ne produit pas localement des centaines de lignes de code de production. C’est la console de commande.
Derrière lui se trouvent des modèles IA, GitHub, CI, le cloud, des environnements de production, la recherche et des outils de développement. Le smartphone transmet l’intention et les contraintes.
La formulation la plus juste n’est donc pas « développer sur un téléphone », mais :
« orchestrer depuis un téléphone des ressources cognitives et informatiques distantes ».
Le datacenter n’est pas entré dans la poche.
La poche a obtenu une télécommande pour le datacenter et l’agent.
2. Pourquoi ce travail est proche du niveau senior
La difficulté ne se mesure pas seulement en lignes de code.
Ce type de modification exige de comprendre l’architecture existante, éviter les doublons, préserver les chemins de production, comprendre les frontières scheduler/GitHub/CI/publication, connecter une nouvelle logique à la boucle centrale, protéger la vie privée, ne pas transformer les données manquantes en zéro, ajouter des tests, distinguer panne de code et panne d’infrastructure, et décider de ce qu’il ne faut pas toucher.
Ce n’est pas seulement réaliser un petit ticket. C’est gérer le rayon d’impact d’un changement dans un système vivant.
Pour un humain, cela ressemble au travail d’un backend senior ou d’un Platform Engineer. Avec la responsabilité de l’architecture globale, une partie du jugement se rapproche du niveau Staff Engineer.
Le difficile n’est pas seulement d’écrire du code sophistiqué.
C’est de savoir où ce code peut vivre sans provoquer d’accident.
3. Quelle était la taille réelle de la modification
Dans un exemple anonymisé, le PR principal contenait 11 fichiers modifiés, 13 commits et environ 895 lignes ajoutées, ainsi qu’un runtime de germination autonome, la préservation de l’Article DNA, un apprentissage comportemental, un feedback limité dans l’optimisation des liens internes, des tests et une définition CI dédiée.
Après le merge, le travail a continué. Des gates ont été ajoutés pour empêcher l’apprentissage comportemental de réécrire le graphe de production avant vérification, et la télémétrie manquante est restée UNKNOWN au lieu de devenir silencieusement zéro.
Ce n’était donc pas « un travail de 895 lignes ».
C’était comprendre le système avant d’écrire 895 lignes, puis construire une cage pour empêcher ces 895 lignes de courir partout.
Le nombre de lignes est une mauvaise unité de difficulté. Cent lignes peuvent supprimer une base de données. Dix mille peuvent produire une calculatrice extrêmement motivée.
4. Combien de temps pour un humain
Pour un bon ingénieur découvrant le dépôt, une estimation grossière de 5 à 15 jours-personnes pour le même périmètre n’a rien d’étrange.
Cela comprend lecture du code et des règles, conception, implémentation, tests, diagnostic CI/infrastructure, revue et vérification de l’impact en production.
Taper le code peut être plus rapide.
En production, prouver qu’on n’a rien cassé peut coûter plus cher que d’écrire le changement.
L’IPA japonaise explique qu’en l’absence d’une autre définition, un mois-personne correspond à 160 heures-personnes, soit 8 heures × 20 jours.[1]
Ainsi, 5–15 jours-personnes représentent environ 0,25–0,75 mois-personne.
5. Quel prix pour embaucher un humain
Il n’existe pas de prix universel. Contrat, responsabilité, connaissance préalable du système, revue et garantie de production changent fortement le coût.
Les tarifs publics donnent toutefois un ordre de grandeur.
Levtech indique qu’un consultant IT freelance à temps plein cinq jours par semaine représentait environ 1,0 à 1,1 million de yens par mois, sur la base de données de juillet 2025.[2]
En divisant simplement par 20 jours ouvrés, cela donne environ 50 000 à 55 000 yens par jour. Pour 5–15 jours-personnes, la main-d’œuvre directe représente environ 250 000 à 825 000 yens.
Un vrai contrat peut être plus élevé avec gestion de projet, revue, risque de reprise, garantie, frais et marge.
Il est donc difficile de considérer cela comme « une petite tâche à quelques milliers de yens ».
Inversement, dire « l’IA a gagné 800 000 yens » serait également trompeur. Sa vitesse, son parallélisme, ses modes d’échec, sa supervision et ses coûts d’outils sont différents.
La conclusion utile est plutôt : un travail qui pouvait consommer plusieurs jours ou semaines d’ingénierie qualifiée peut désormais être déclenché par une personne depuis un très petit appareil.
6. Six heures d’agent = six heures de senior ?
Non.
L’IA ne fait pas de pause café, n’est pas aspirée par des réunions, ne perd pas du temps dans les notifications et ne fixe pas le plafond en se demandant qui a validé l’architecture.
Mais elle peut avancer très vite avec une mauvaise hypothèse, mal lire l’état de production, confondre panne du runner et panne du code, élargir des permissions ou confondre « un test existe » avec « le test a réellement réussi ».
Il faut donc juger la modification terminée, les preuves, la vérification et le readback de production, pas seulement l’horloge.
« Six heures et toujours au travail : persévérant » est acceptable.
« Six heures, donc six heures correctes » ne l’est pas.
7. Que devient la valeur de quelqu’un qui ne sait pas tout coder
Le rôle change.
Autrefois, une idée exigeait souvent d’apprendre Git, un langage, un framework, le déploiement et les tests avant de devenir un logiciel.
Les agents IA réduisent cette friction d’implémentation.
Le travail humain à forte valeur se déplace vers : quoi construire, pourquoi, ce qui ne doit jamais casser, jusqu’où l’automatisation peut modifier, ce qui compte comme succès, ce qui doit rester UNKNOWN et quand une panne doit tout arrêter ou être isolée.
« Pouvoir écrire personnellement chaque ligne » n’est plus l’unique ticket d’entrée.
Cela ne rend pas la compréhension technique inutile. Plus on comprend objectifs, risques, dépendances et vérification, meilleures sont les instructions.
On n’a pas besoin de fabriquer un moteur pour conduire.
Mais il faut savoir ce que signifie un feu rouge.
8. Pourquoi « laisser l’IA tout faire » est dangereux
La panne la plus inquiétante n’est pas l’écran d’erreur.
C’est avoir tort avec l’apparence du succès.
Un PR peut être merged sans être déployé; un fichier CI peut exister sans qu’aucun runner n’ait commencé une étape; des données indisponibles peuvent devenir zéro; ancienne et nouvelle logique peuvent s’exécuter en double; la « sécurité » peut arrêter toute l’automatisation; « l’autonomie » peut élargir les droits trop loin.
Une bonne automatisation n’est pas seulement celle qui continue d’avancer.
C’est celle qui distingue les faits de ce qui n’est pas vérifié tout en avançant.
9. Comment déléguer plus sûrement depuis un smartphone
Définir d’abord le résultat
Ne dites pas seulement « modifie ce fichier ». Dites ce qui doit être vrai à la fin.
Écrire les invariants
Fonctions existantes, vie privée, règles d’images, chemins de publication, SEO: ce qui ne doit pas casser.
Définir l’autorité
Préciser si l’agent peut écraser, ouvrir un PR, merger ou toucher la production.
Lire l’état actuel d’abord
Préférer current main, runtime réel et public state réel aux anciennes conversations.
Inclure la vérification dans le livrable
« Code écrit » n’est pas terminé. Tests, CI et production readback peuvent être nécessaires.
Autoriser UNKNOWN
Ne forcez pas l’inconnu en PASS ou FAIL.
L’écran du téléphone est petit.
La responsabilité de la spécification ne l’est pas.
10. Conclusion : peut-être que c’est la barrière d’entrée qui s’est cassée
Une personne qui ne peut pas écrire seule du code de production avancé peut désormais diriger pendant des heures un agent IA depuis son téléphone et intégrer dans GitHub des modifications contenant du jugement architectural de niveau senior.
Il y a quelques années, cette phrase semblait étrange.
Aujourd’hui, elle peut être opérationnellement vraie.
Cela ne signifie pas que les ingénieurs sont inutiles.
Une partie de la valeur se déplace de l’implémentation manuelle vers l’architecture, les contraintes, la vérification et les frontières de responsabilité.
L’IA ne supprime pas la valeur.
Elle déplace l’endroit où elle se trouve.
Et le plus grand changement est peut-être que ceux qui s’arrêtaient à « techniquement, je ne sais pas construire cela » peuvent commencer une question plus tôt :
« Alors, que devrions-nous construire ? »
Le smartphone reste une plaque de verre.
Mais cette plaque peut maintenant devenir la télécommande de ressources d’ingénierie de niveau senior.
Oui, le monde semble un peu cassé.
D’une manière assez intéressante.
Sources
- IPA, FAQ Software Development Data White Paper. Conversion par défaut: 1 mois-personne=160 heures-personnes (8×20) ipa.go.jp
- Levtech, guide des coûts de conseil IT, mis à jour le 2026-08-18. Environ ¥1,0–1,1 million/mois pour un consultant IT freelance à temps plein, données de juillet 2025 levtech.jp
