L'ingénierie logicielle est morte. C'est ce que les voix les plus bruyantes de la tech sur Twitter veulent vous faire croire. Elles partagent des enregistrements d'écran d'outils d'IA générant des applications complètes à partir d'un simple paragraphe et demandent pourquoi quelqu'un paierait encore un humain pour écrire du code. La panique est compréhensible, mais elle passe totalement à côté de l'essentiel.
L'IA ne vient pas remplacer les ingénieurs. Elle vient pour tous ceux qui confondent vitesse de frappe et jugement technique. Il existe un fossé immense entre le codage et l'ingénierie, et c'est dans ce fossé que réside toute la profession.
Un assistant IA peut vous proposer cinq manières différentes d'implémenter une fonctionnalité avant même que vous n'ayez fini de siroter votre café. Le goulot d'étranglement s'est déplacé. Nous ne fixons plus un fichier vide en nous demandant par où commencer. Nous fixons cinq solutions plausibles en nous demandant laquelle ne s'effondrera pas dès que le trafic réel arrivera. Cette décision, c'est de l'ingénierie. Tout le reste n'est que de la syntaxe.
La démo n'est pas le produit
Regardez n'importe quelle démo de codage par IA et vous verrez une interface magnifique se construire en quelques minutes. Ce que vous ne verrez pas, c'est le pool de connexions à la base de données qui s'épuise sous la charge. Vous ne verrez pas l'absence de limites de débit sur un point de terminaison d'API, l'absence de journaux d'audit, ou les coûts de stockage liés à l'enregistrement de chaque interaction utilisateur dans un bucket d'objets parce que l'IA a pensé que c'était un endroit pratique pour y déverser l'état.
Les systèmes de production exigent de la scalabilité, de la sécurité, de la performance et un contrôle des coûts. Ces qualités sont invisibles lors d'une revue de sprint. Elles ne se révèlent que lorsque les utilisateurs réels arrivent avec leur comportement imprévisible, leurs cas limites et leur refus de cliquer sur les boutons dans l'ordre prévu. J'ai vu trop de projets assistés par l'IA qui semblaient parfaits en QA se transformer en leçons coûteuses la semaine suivant le lancement.
Le code fonctionnel est devenu bon marché. Une bonne ingénierie ne l'est pas.
Ce qui compte désormais
Les ingénieurs qui prospèrent dans cette transition ne sont pas ceux qui tapent le plus vite. Ce sont ceux qui savent quelles questions poser avant même qu'une seule ligne ne soit générée.
Ils définissent les problèmes avec clarté. Un modèle d'IA résoudra avec plaisir le mauvais problème si vous le laissez faire. Il construira une couche de mise en cache complexe pour un tableau de bord à forte lecture qui n'est utilisé que par six analystes internes. Il ne s'arrêtera pas pour demander si le véritable problème est un index de base de données manquant ou un modèle de données fondamentalement erroné. Un ingénieur qualifié reformule le problème jusqu'à ce que la solution devienne évidente, que cette solution implique du code ou non.
Ils décomposent les grands systèmes en éléments plus petits. L'IA excelle dans le contexte local. Elle peut écrire une fonction unique, un composant unique, un test unique. Elle a du mal à appréhender une architecture distribuée complète. Les ingénieurs capables de décomposer un monolithe, de tracer des frontières autour des services et de définir des contrats entre les équipes sont ceux qui transforment des extraits générés en systèmes durables.
Ils contestent les suggestions de l'IA. La confiance du modèle est un mirage. Il proposera des architectures qui ignorent la latence réseau, recommandera des bibliothèques obsolètes depuis des années ou résoudra des fonctionnalités qui n'existent pas réellement dans les exigences.