Leaders d’opinion

Codage Vibe, IA et la nouvelle réalité de l’ingénierie

mm
Ajouter Unite.AI à vos sources préférées sur Google

Il y a dix ans, l’idée que l’IA puisse écrire du code à la place des programmeurs semblait plus comme une fantaisie excitante. Aujourd’hui, elle est devenue une partie de la réalité quotidienne. Les MVP sont construits en quelques jours, les interfaces sont générées à partir de invites de texte, et les assistants IA deviennent des participants à part entière dans les équipes d’ingénierie.

Face à cela, de plus en plus de personnes se posent les mêmes questions: L’IA remplace-t-elle vraiment les programmeurs ? L’intelligence artificielle peut-elle vraiment égaler et remplacer un ingénieur senior ? Et que se passera-t-il de la profession dans un avenir proche ?

Je suis moi-même un développeur, et j’ai une opinion sur ce sujet. Commençons par le commencement.

Quel est le cœur du problème ?

Il y a un récit dominant sur la programmation IA qui va comme suit:

L’IA devient extrêmement efficace pour écrire du code et, ce qui est important, évite déjà de nombreuses erreurs courantes que les humains font. Plus intéressant encore, l’IA pourrait être meilleure pour gérer les cas de bordure, les scénarios rares et inhabituels qui sont omniprésents dans l’ingénierie logicielle et souvent difficiles pour les développeurs à anticiper à l’avance.

Lorsque le programmeur dit : « Je veux un bouton ici », il obtient une réponse : « Voici le bouton, voici 18 cas de bordure que vous devriez considérer, voici les tests que vous devez effectuer, et au fait, vous voudrez peut-être également ajouter ceci et cela. » Vous pouvez regarder cela et penser : « Oui… cela a vraiment du sens. » À vous seul, vous auriez peut-être réalisé ces problèmes des semaines plus tard – après que quelque chose se soit déjà passé dans la production. L’IA suggère souvent des solutions immédiatement. Pour les ingénieurs qui ont déjà des emplois, cela augmente considérablement la productivité et l’efficacité.

Et ce récit conduit directement à une question économique : si une entreprise avait besoin de 100 développeurs pour gérer une charge de travail donnée, elle n’a peut-être besoin que de 20 maintenant – parce que ces 20 peuvent accomplir la même quantité de travail avec l’aide de l’IA.

Qu’est-ce qui se cache derrière cette accélération ?

De plus en plus souvent, je vois des ingénieurs logiciels très solides craindre pour leurs postes, leur place sur le marché et leur revenu. On dirait qu’il ne restera bientôt plus de travail pour les codeurs.

Et ma réponse est généralement : les gars, ce n’est probablement pas aussi dramatique qu’il n’y paraît. En fait, les ingénieurs expérimentés gagnent une nouvelle sorte de valeur en ce moment. Parce que nous sommes peut-être l’une des dernières générations de développeurs qui ont réellement écrit du code à la main et qui comprennent profondément comment les systèmes fonctionnent sous le capot. La prochaine génération travaille de plus en plus avec des outils IA – et avec cela, la pratique d’ingénierie elle-même change.

Voici ce que le récit précédent ne prend pas en compte :

Le code généré par l’IA a souvent l’air parfait. Les tâches sont résolues, les interfaces fonctionnent et tout fonctionne. Mais au fil du temps, à long terme, des problèmes plus subtils commencent à apparaître : compromis architecturaux, décisions d’ingénierie faibles, problèmes de structures de données ou problèmes de scalabilité. Et cela se produit parce que l’IA est déjà très bonne pour résoudre les tâches locales, tandis que la logique à long terme des grands systèmes nécessite encore l’expérience humaine et le jugement d’ingénierie.

C’est pourquoi, une fois que ces projets atteignent des environnements de production sérieux – banques, plateformes de commerce électronique, grandes entreprises de services – les équipes ont encore besoin de personnes qui peuvent analyser en profondeur l’architecture, identifier les causes profondes et restaurer la logique globale du système.

Je reçois souvent des appels de amis qui disent des choses comme : « Michael, pouvez-vous sauter dedans et nous aider à comprendre pourquoi le système commence à se décomposer ? » Même si aujourd’hui je travaille sur l’IA physique chez Introspector, je peux encore occasionnellement aider avec ce type de travail d’ingénierie manuelle difficile : reconstruire la logique du système, analyser l’architecture et déterminer où les problèmes ont commencé à s’accumuler.

Et c’est exactement pourquoi je crois que les ingénieurs solides resteront très précieux pendant longtemps. Dans le même temps, ce sont souvent les ingénieurs expérimentés qui aident à améliorer et à former les modèles IA aujourd’hui. Chez Keymakr, nous avons vu cela de visu lors de la recherche de développeurs expérimentés pour valider le code et aider à former les modèles – des personnes qui peuvent s’appuyer sur une réelle pensée d’ingénierie, une expérience pratique et une compréhension profonde de la façon dont les systèmes se comportent dans le monde réel.

Les principales hypothèses

Et cela nous amène à la plus grande question sur l’avenir : où tout cela mène-t-il finalement ? Comment allons-nous faire grandir la prochaine génération d’ingénieurs si elle entre dans l’industrie par un chemin complètement différent dès le début ?

Si nous regardons la situation objectivement, sans hype ni peur, je vois quelques scénarios possibles.

  • Un avenir incertain

La première et probablement la plus honnête réponse est que très peu de personnes réfléchissent vraiment à l’avenir. Simplement parce que personne ne comprend encore pleinement à quoi ressemblera cet avenir dans la pratique.

Peut-être, dans quelques années, les agents IA seront-ils vraiment capables d’écrire un code presque parfait – avec une forte architecture, une scalabilité et une compréhension contextuelle. Pour l’instant, cette question est encore complètement ouverte.

Dans le même temps, les grandes entreprises technologiques comme Apple, Microsoft et Google continuent d’embaucher activement des chercheurs solides, des spécialistes du doctorat et des personnes de milieux universitaires. Cela suggère probablement qu’ils croient que la compréhension approfondie de l’ingénierie restera importante même dans un monde où la plupart du code est généré automatiquement.

Les petites entreprises, cependant, opèrent souvent avec un horizon de planification très différent. Lorsque vous ne savez pas si votre startup existera encore dans six mois, il devient difficile de réellement penser à ce qui se passera dans dix ans. Bien sûr, personne n’a l’intention de construire quelque chose de fondamentalement cassé. Les équipes essaient encore d’identifier les risques et les faiblesses potentiels.

Mais dans la réalité, la logique est souvent beaucoup plus simple : d’abord, construisez un produit qui fonctionne et génère des revenus – puis traitez de l’architecture, de l’optimisation et de la réécriture du système plus tard. Le problème est que, dans de nombreux projets, « plus tard » est constamment reporté sine die.

  • Évolution en spirales

La deuxième réponse, à mon avis, est encore plus intéressante. Si vous regardez l’histoire de l’industrie, elle a déjà traversé des transitions similaires de nombreuses fois auparavant. Les premiers programmeurs travaillaient avec des cartes perforées. Puis vint la génération d’ingénieurs écrivant en langage assembleur – quelque chose qui est déjà difficile pour de nombreux développeurs modernes à imaginer.

Ensuite vint l’ère du COBOL. Des mainframes bancaires entiers ont été construits sur celui-ci, et la partie la plus surprenante est qu’une partie importante de l’infrastructure bancaire mondiale fonctionne encore sur ces anciens systèmes aujourd’hui. Il y a encore des programmeurs dans la soixantaine et la soixante-dixaine qui maintiennent cette base de code, et ils restent des spécialistes extrêmement précieux.

La génération suivante est passée à C++, Python et JavaScript. Je fais partie de cette ère. Par exemple, je comprends à peine comment fonctionne le COBOL. En théorie, je pourrais l’apprendre – mais pour moi, cela me semble déjà lointain et étranger.

Et lorsque vous regardez cela historiquement, un modèle intéressant émerge : chaque nouvelle génération d’ingénieurs n’a plus besoin de comprendre profondément comment la technologie de la génération précédente fonctionnait. Au fil du temps, les connaissances sont intégrées dans l’infrastructure elle-même.

Les cartes perforées ont disparu il y a longtemps – leur logique est maintenant intégrée dans les processeurs. L’assembleur a en grande partie disparu en tant qu’outil principal parce que sa complexité est devenue cachée dans les systèmes d’exploitation, les pilotes et les abstractions de bas niveau. Même vos écouteurs d’aujourd’hui contiennent probablement un petit système d’exploitation qui exécute toute cette complexité cachée en arrière-plan – la plupart des gens ne pensent simplement jamais à cela.

Bien sûr, il y a encore des spécialistes qui comprennent tout cela de magie de bas niveau. Mais pour la plupart de l’industrie, cela est déjà devenu une couche d’abstraction.

Et cela conduit à une idée très logique : peut-être que l’IA est simplement la prochaine étape de cette évolution. Peut-être que la prochaine génération n’aura vraiment pas besoin de comprendre la programmation classique aussi profondément que nous l’avons fait.

  • L’économie du marché

Une autre hypothèse que j’ai est que le codage vibe – ou le développement assisté par IA – finira par cesser d’être perçu comme une « accélération gratuite ». En réalité, ce n’est déjà pas entièrement gratuit ; c’est juste que, pour l’instant, tout le monde ne calcule pas soigneusement les véritables économies derrière cela.

Les modèles, les jetons, l’infrastructure, les demandes constantes, le maintien de l’ensemble du pipeline IA – tout cela devient progressivement une dépense opérationnelle significative. C’est pourquoi je crois que les entreprises commenceront bientôt à regarder beaucoup plus attentivement le coût réel du développement assisté par IA et à se poser une question très pragmatique : qu’est-ce qui est réellement plus efficace – étendre une équipe d’ingénieurs ou maintenir l’ensemble de l’infrastructure IA autour du développement ?

Un scénario très réaliste est que les équipes d’ingénierie solides s’avèrent finalement plus durables sur le plan économique, en particulier lorsqu’il s’agit de maintenir, de faire évoluer et de soutenir les produits à long terme.

Cependant, je pense que c’est là que peut émerger un nouveau type d’équipe d’ingénierie : de très petits groupes d’experts très expérimentés qui se concentrent sur le maintien de la stabilité et de la résilience de l’infrastructure elle-même. Au fil du temps, cela peut devenir l’une des spécialisations d’ingénierie les plus précieuses de l’industrie.

  • Les personnes qui travailleront aux côtés de l’IA

Et la dernière hypothèse – bien que très réaliste – est que la prochaine génération d’ingénieurs devra probablement construire leur carrière dans un environnement complètement différent. Et cela va bien au-delà de la programmation seule. Des changements similaires commencent déjà à remodeler le droit, la finance, la médecine et presque tous les domaines où l’IA peut prendre en charge une partie importante du travail intellectuel de routine.

Malgré tout cela, je tends à considérer ce qui se passe de manière plutôt positive. Probablement parce que, dans l’ensemble, j’aime vraiment le progrès. J’aime l’idée que la technologie peut améliorer la vie des gens, libérer les humains d’une énorme quantité de travail répétitif et rendre de nombreux processus plus sûrs et plus efficaces.

Par exemple, les systèmes de conduite autonome comme ceux de Tesla ou de Waymo démontrent déjà des niveaux de sécurité remarquablement élevés dans de nombreux scénarios par rapport aux conducteurs humains. Et cela est vraiment impressionnant.

Dans le même temps, le monde dans lequel nos enfants entrent sera beaucoup plus compliqué en termes d’identité professionnelle. Ils devront chercher leur place et leur but dans un paysage en constante évolution.

Si un enfant veut devenir avocat, analyste financier ou programmeur aujourd’hui, il y a une forte chance que ces professions soient complètement différentes à l’avenir. Peut-être que celles-ci deviendront des spécialistes qui travaillent en étroite collaboration avec l’IA juridique, l’IA financière ou l’IA de codage – des personnes qui exploitent les systèmes IA, valident les sorties, fournissent le contexte et prennent les décisions clés.

Je pense qu’il est important de reconnaître que presque tous ces scénarios sont déjà réalistes aujourd’hui. Et que nous le voulions ou non, tout ce qui se passe maintenant fait partie d’une grande vague de progrès technologique. Il est très peu probable que ce processus puisse être arrêté. Ce qui signifie que nous devrons apprendre à vivre dans ce nouveau monde – en apprenant progressivement à l’équilibrer, à communiquer avec lui et peut-être même à développer une nouvelle forme de coexistence à ses côtés.

Michael Abramov est le fondateur et PDG d'Introspector, apportant plus de 15 ans d'expérience dans l'ingénierie logicielle et les systèmes d'intelligence artificielle de vision par ordinateur pour construire des outils de labellisation de niveau entreprise.

Michael a commencé sa carrière en tant qu'ingénieur logiciel et responsable de la R&D, construisant des systèmes de données évolutifs et gérant des équipes d'ingénierie multifonctionnelles. Jusqu'en 2025, il a occupé le poste de PDG de Keymakr, une société de services de labellisation de données, où il a innové les flux de travail humains dans la boucle, les systèmes de QA avancés et les outils sur mesure pour répondre aux besoins de vision par ordinateur et d'autonomie à grande échelle.

Il détient un B.Sc. en informatique et une formation en ingénierie et arts créatifs, apportant une approche multidisciplinaire pour résoudre des problèmes complexes. Michael vit à l'intersection de l'innovation technologique, du leadership produit stratégique et de l'impact réel, poussant les frontières de l'autonomie et de l'automatisation intelligente.