Comment les développeurs peuvent garder leur emploi (2)
Des figures connues du secteur du logiciel ont rendu banale l'alerte sur le tarissement du vivier de talents. Être d'accord est confortable. Cette deuxième partie de la série prend donc plutôt au sérieux le camp d'en face.
Architecture logicielle
Voici les liens vers les articles de cette série :
- Partie 1 : Sur quoi les entreprises parient avec l'IA
- Partie 2 : Ce que disent les optimistes et ce que j'en pense
- Partie 3 : Mes recommandations pour vous en tant que développeur, et pour vous en tant que manager
Apparemment, je ne suis pas le seul à voir le problème : le muscle de la programmation s'affaiblira à mesure qu'on s'en sert moins. Le « pipeline RH » cessera de transformer les juniors en seniors si les entreprises s'en tiennent à l'idée de ne plus embaucher de juniors.
Il y a deux ans, Charity Majors, cofondatrice et CTO de honeycomb.io, signalait le même piège dans son essai sur le blog de Stack Overflow. Je pourrais donc simplement me sentir conforté et savourer, non ? Mais ce serait trop facile.
L'argument des optimistes
Simon Willison soutient que livrer du code moins bon avec des agents est un choix, et que le refactoring est une tâche idéale pour les agents.
Simon n'est pas n'importe qui : il est l'un des créateurs du framework web Django. Il a aussi forgé le terme prompt injection. Il défend le coding agentique, mais avec un œil critique.
Comme moi, Simon trace une ligne nette entre deux choses : le vibe coding, où l'on ne vérifie plus le code, et le développement responsable assisté par l'IA. (Malheureusement, beaucoup de gens utilisent désormais le nom « vibe coding » aussi pour le second, ce qui dilue le terme.)
Charlie Graham, un fondateur, est encore plus optimiste et va plus loin : la dette que le modèle d'aujourd'hui ne voit pas, le suivant la trouve, elle ne dure donc que quelques mois.
La dette technique était autrefois quelque chose qui s'accumulait et dépassait vite la capacité des gens à refactoriser. Simon et Charlie disent que l'IA a changé cela. S'ils ont raison, la crise que je prédis n'arrivera tout simplement pas.
Jusqu'où les optimistes ont raison
La duplication, les fonctions trop longues, les tests manquants et les noms incohérents sont des problèmes locaux. Les modèles savent bien les corriger aujourd'hui et s'y améliorent. Je concède ce point : mon hypothèse de départ était trop large.
Les modèles sont bons pour des tâches comme celles-ci :
1. Fusionner le code dupliqué. Un modèle repère la même logique de validation, légèrement variée, dans cinq contrôleurs et la regroupe dans une fonction commune. Vous pouvez vérifier la modification fichier par fichier, car le comportement doit rester le même et les tests existants le prouvent.
2. Découper les fonctions trop longues. Une méthode de 300 lignes est divisée en étapes nommées, comme vérifier l'entrée, calculer et enregistrer. Pour cela, le modèle n'a besoin de comprendre que cette fonction et ses appelants directs, pas tout le système.
3. Ajouter les tests manquants. Pour une fonction existante, un modèle écrit des tests unitaires qui couvrent le cas normal, les valeurs limites et les cas d'erreur. Cela marche bien, car le comportement attendu se lit dans le code lui-même, et l'exécution des tests montre tout de suite s'ils sont justes.
4. Rendre les noms et le style cohérents. Quand la même chose s'appelle « customer » à un endroit, « client » à un autre et « user » à un troisième, un modèle la renomme de façon cohérente dans tout le projet. C'est un travail ingrat et fastidieux sur de nombreux fichiers, mais il ne demande aucune décision de conception, et les erreurs apparaissent tout de suite dans le compilateur ou le linter.
Ce que ces quatre exemples ont en commun : l'information nécessaire se trouve dans le code, et le résultat peut être vérifié automatiquement.
Mon argument porte plutôt sur l'architecture : des structures fondamentales, qui demandent beaucoup d'expérience, de vue d'ensemble et de jugement, parfois même du goût. On ne peut pas les déduire d'un seul endroit du code.
Charlie Graham admet que la majeure partie de la dette technique ne concerne pas l'architecture :
But most technical debt is not architecture. It is imperfect implementation around an unproven idea. The slightly wrong abstraction. The feature built before anyone knew if users wanted it. The elegant system designed for a scale that never arrived.
Mais il suppose que les modèles pourraient aussi résoudre cela, dès 2027.
Je ne suis pas d'accord. Une architecture cassée n'est pas un fichier en désordre. C'est une mauvaise décision. L'information nécessaire pour la corriger (exigences à venir, contraintes réelles, principes de conception et d'évolution) ne se trouve tout simplement pas dans le code. Un humain expérimenté doit donc la donner à l'IA, sinon elle ne peut pas la connaître.
Mon hypothèse, désormais révisée
Les optimistes m'ont obligé à préciser mon hypothèse, et je leur en suis reconnaissant. Sur un point, ils ont raison : les modèles nettoient déjà aujourd'hui le code dupliqué, les fonctions trop longues et les tests manquants, et ils s'y améliorent. Qui attend ici la grande crise attendra en vain.
Mon hypothèse se lit donc désormais ainsi : De meilleurs modèles élimineront le désordre local. Mais pour l'instant, ils ne décideront pas de ce que le système doit devenir. La raison en est le manque d'information. Quelles exigences arriveront l'an prochain, quelles contraintes sont réelles et lesquelles se sont simplement installées avec le temps, ce que l'activité peut supporter pendant une refonte, et ainsi de suite : rien de tout cela n'est dans le code.
Cette décision demande quelqu'un doté de jugement, qui comprend l'architecture et maîtrise les outils. Le modèle exécute la refonte. Un humain doit répondre de la direction qu'elle prend.
L'offre qui se réduit
Si c'est vrai, les ingénieurs les plus précieux de la prochaine décennie seront justement ceux que les entreprises viennent de cesser de former. Dans le prochain épisode : qui gagne, où je pourrais me tromper, et à quoi les développeurs et les entreprises devraient faire attention.