L’IA et les métiers du dév

Pour échanger très régulièrement avec des profils tech et dev, je vois clairement une scission s’opérer. On a d’un côté les techs réfractaires à l’IA (peu importe leurs raisons) et les convaincus qui l’utilisent au quotidien. Et l’écart entre les deux semble pour l’instant se creuser.

Je ne crois pas qu’on se dirige pour autant vers un monde avec les humains naturels d’une part et les humains augmentés d’autre part. D’ici quelques années, de bonnes pratiques IA vont faire consensus et l’IA sera intégrée dans les boites à outils de chacun.

PS : Il n’y a pas de logique ou de priorité dans les 9 points qui suivent.

L’IA et le prototypage rapide

L’IA fonctionne très bien pour tester et monter rapidement des prototypes. Ce qui importe, c’est d’avoir une maquette manipulable et de collecter des retours terrains. Pour cet usage, il y a un vrai gain de temps, du budget économisé et de nouvelles possibilités offertes aux amateurs et aux profils qui ont un vernis tech sans avoir de bases solides.

L’IA et la création de SAAS

Entre le prototypage et la réalisation d’un vrai outil exploitable dans des conditions réelles de production avec des problématiques de design logiciel, de montée en charge, de mise en conformité avec des standards, de cycle de vie et d’évolutivité, de dimensionnement des ressources matérielles, l’IA ne séduit que les non techniciens.

Entre faire un prototype et avoir un logiciel robuste, il y a un gouffre. Et il n’est pas forcément facile à argumenter que la plus-value de vrais profils techniques est nécessaire pour passer d’un proto 100% IA à un logiciel qui « fait la même chose » mais qui le fait bien.

Le négliger, c’est à minima faire face dans la douleur à des bugs et des coûts de maintenance et de redesign inutilement élevés et au pire à une explosion en plein vol car étant dans l’impossibilité de s’adapter à temps.

L’IA et l’assemblage de briques logicielles

Vous êtes plutôt Make ou N8N ? Brancher des outils les uns à la suite des autres pour aboutir à des process qui automatisent vite et bien est une réalité. Mais une réalité qui a du mal à passer le stade de la bricole.

Se reposer sur des modules logiciels externes fait gagner du temps, mais fait perdre en contrôle et rend dépendant. Évidemment, tout le monde utilise des API (on ne réinvente pas la roue). Maintenant, construire un SAAS et se dire pro impose d’être un peu exigeant et implique de rendre des comptes. Trouveriez-vous normal que votre comptable vous dise qu’il a perdu une facture parce qu’il y a eu un bug mais que ce n’est pas sa faute parce qu’il y a eu une interruption de service chez un des services ou bien qu’il y a eu une incompatibilité entre 2 de ses outils censés discuter ensemble ?

Les branchements d’outils qu’on réalise avec les outils d’automatisation sont trop souvent de la bidouille. Les habitués du SQL savent par exemple que les procédures stockées permettent de s’assurer qu’un ensemble d’actions s’est bien réalisé sans accroc et que dans le cas contraire, tout est déconstruit pour revenir à l’état initial. Pour les outils d’automatisation, qui contrôle que chaque étape s’est effectivement bien passée ? Qui se préoccupe de savoir si les données reçues sont bien celles attendues ? Qui fait des tests avec des données volontairement non souhaitées ? Qui a des mécanismes d’alerte en cas de réponse inattendue ?

Un dev fait cela parce qu’il sait que c’est important pour avoir un logiciel stable, fiable et que ça lui simplifiera la vie plus tard. Sauf que ces outils qui permettent d’emboiter des fonctionnalités sont justement destinés à des non techs.

L’IA et les dev juniors

Savoir faire des copier-coller ne transforme pas n’importe qui en codeur. Si le trafic de Stackoverflow s’est effondré, c’est certainement que les apprentis dev ont migré sur les outils d’aide à la création de code. Soit ChatGPT ou Claude, soit des outils dédiés pour le développement tel que Github Copilot.

Écrire le code, c’est la partie la plus facile

Un non-dev ne s’en rend pas compte. Ce qui fait qu’un code fonctionne, c’est parce qu’il a été bien pensé, bien écrit et bien testé. Le plus difficile n’est pas de l’écrire, mais de le comprendre, de l’exploiter et de bien le faire vieillir. Et ça, ça ne se voit pas. Et ce n’est pas aussi fun que de regarder ChatGPT pisser du code.

C’est pour ça que l’IA écrit du code mais ne fait pas le reste. Il y a encore de l’avenir pour les devs qui lèvent les yeux de leurs écrans et travaillent en pensant à l’implication de leur code dans un tout plus grand.

L’IA qui créée du code

Chez Google, 25% du code généré est fait par l’IA. Et en interne, ça râle parce que le temps gagné dans la création initiale est compensée en temps de débuggage et de refactorisation, 2 tâches que la plupart des devs n’apprécient pas vraiment.

Se pose alors la question de la qualité produite : dans un monde parfait, on voudrait tous un code propre, rapide et juste. Dans les faits, produire un code juste valable suffit. Et tant pis s’il faut parfois se plonger dedans pour faire des ajustements.

L’IA et la santé mentale des techs

Faire du code est une activité intense pour le cerveau. Si tant de devs ont besoin d’être dans leur bulle (avec des écouteurs) et de ne pas être dérangé, c’est pour être dans le bon état d’esprit (le flow) : concentration maximale, satisfaction de produire du bon code…

Et l’IA, sans permettre d’atteindre le flow, génère du bien-être chez les codeurs qui disent être plus rapides dans leurs tâches, satisfaits de leurs productions, moins frustrés de leur activité de code. L’IA permet aussi de rester concentré plus longtemps et d’économiser ses ressources mentales. Voir l’étude de Github Copilot.

À tempérer : lorsque les développeurs sont mis en concurrence avec l’IA ou que les entreprises ne voient que les résultats et les coûts à court terme, je suis certain que la situation est complètement opposée.

L’IA et le travail en équipe

0 pointé pour l’IA sur les soft skills. Ce n’est pas parce que les devs préfèrent les moyens de communication asynchrone (pour ne pas être dérangé durant les sessions de code) qu’ils ne travaillent pas bien en équipe.

Pouvoir échanger, se sentir valorisé et reconnu pour son travail par ses collègues et son manager, ça n’a pas de prix. Dans les quelques entreprises pour lesquelles le télétravail est la norme, des rencontres « en vrai » et des rituels pour renforcer les liens sont nécessaires (voir Automattic).

L’IA à la place de l’équipe ?

Les bonnes équipes de dev ont des profils juniors, intermédiaires et seniors. L’IA peut servir en fonction annexe à chaque profil, mais ne les remplace pas.

Si l’IA remplace les juniors, que va-t-il se passer lorsque les seniors partiront ? Le dev fait partie de ces métiers ou les plus compétents tirent les novices vers le haut. C’est un métier d’artisan qui s’apprend sur l’ouvrage en faisant et en refaisant. Et même si l’IA fait le code des juniors, qui pilote l’IA et qui est capable de juger sa production ?

Un petit mot de conclusion ?

• C’est facile de produire du code, c’est plus difficile de produire du code de qualité.
• C’est faux d’imaginer que le dev, c’est simplement faire du code.
• C’est dangereux de faire croire qu’un outil peut coder aussi bien qu’un humain.

Il n’y a aucune raison pour que les dev curieux et ouverts ne soient pas toujours indispensables en entreprise. Si vous êtes arrivés jusqu’en bas de cet article, seriez-vous OK pour laisser un commentaire ? Quel est votre ressenti ?