Là où l'IA me fait gagner du temps et là où elle me ralentit

J'utilise l'IA tous les jours, et je ne voudrais pas revenir en arrière.

C'est probablement la façon la plus simple de commencer. L'IA m'a rendu plus rapide, m'a aidé à apprendre plus vite et a rendu des pans entiers de l'ingénierie plus accessibles qu'avant. Elle a changé ma façon de démarrer un travail, de trouver du contexte, d'écrire du code, de tester et de me déplacer dans des parties de la stack qui m'étaient autrefois peu familières.

Chez Webflow, nous réfléchissons beaucoup à la place de l'IA dans le workflow d'ingénierie. Pas seulement comme générateur de code, ni comme raccourci pour contourner le jugement, mais comme un moyen d'aider les gens à avancer sur du vrai travail produit avec plus de contexte et moins de friction.

Cette distinction compte pour moi, car les workflows d'IA les plus utiles consistent rarement à écrire du code plus vite. Il s'agit de connecter l'assistant au bon contexte, aux bons systèmes et aux bonnes contraintes pour que le travail démarre plus près de la réalité.

Mais l'IA n'a pas rendu l'ingénierie magiquement facile.

Le travail pénible n'a pas disparu. Dans certains cas, il a simplement changé de tenue et est revenu avec un meilleur CV.

Pour moi, le plus grand changement est le suivant :

L'IA a rendu le démarrage et l'exécution du travail beaucoup plus rapides.

La partie la plus lente, c'est tout ce qui vient après : relire le résultat, comprendre les hypothèses, garder des PR assez petites pour être relues, fusionner les choses dans le bon ordre, et m'assurer de pouvoir encore expliquer le code deux semaines plus tard.

C'est là que se situe le vrai compromis.

Avant le premier jet

Avant que l'IA ne fasse partie de mon quotidien, une grande partie de l'ingénierie consistait à chasser le contexte.

Une journée normale commençait dans des endroits familiers. Slack. Jira. Les tâches assignées. Confluence. La documentation interne. La documentation des outils. La documentation des frameworks. Puis, selon la rapidité à laquelle les choses dérapaient, Google, Stack Overflow, Reddit, GitHub Issues, et finalement un collègue qui avait peut-être déjà vu la même chose.

Parfois, cela devenait du pair programming. Parfois une session de débogage. Parfois deux heures à essayer différentes choses, que je décrivais ensuite comme de l'« investigation », ce qui est techniquement vrai et émotionnellement généreux.

C'était particulièrement vrai plus tôt dans ma carrière, quand je me concentrais surtout sur l'ingénierie front-end. Passer du front-end au back-end, aux bases de données et au full-stack a pris du temps. J'ai dû apprendre de nouveaux systèmes, de nouveaux frameworks, de nouveaux modes de défaillance et de nouveaux types de contexte.

React a changé. L'outillage a changé. Les bibliothèques ont changé. Des paquets NPM refusaient de s'installer pour des raisons qui semblaient personnelles.

Une grande partie du travail ne consistait pas seulement à écrire du code. C'était d'obtenir assez de contexte pour écrire le bon code.

Et parfois, la partie la plus lente de la tâche, c'était tout ce qui se passait avant la première vraie ligne de code.

La vitesse du démarrage

L'IA a radicalement changé cette première étape.

Aujourd'hui, avec MCP et des outils connectés, je peux obtenir du contexte pertinent beaucoup plus vite. Au lieu de sauter manuellement entre Slack, Confluence, Jira, les docs internes, la documentation web et la base de code, je peux demander à l'IA de m'aider à rassembler et à synthétiser ces informations.

C'est aussi pourquoi MCP est intéressant au-delà du cas d'usage « l'IA écrit du code ». MCP donne aux assistants une manière plus structurée de travailler avec les outils et les systèmes où le vrai travail se fait déjà. Par exemple, la plateforme développeur de Webflow prend en charge MCP pour que des agents puissent travailler avec les workflows Webflow depuis des outils comme Claude, Cursor, Postman ou d'autres clients compatibles MCP.

Pour moi, c'est une version de l'IA bien plus utile qu'une fenêtre de chat vide. Ce n'est pas seulement un assistant qui devine de l'extérieur. C'est un assistant qui peut opérer plus près du workflow réel, avec un contexte plus clair et des actions plus pertinentes.

Si je démarre une nouvelle fonctionnalité, je peux demander le contexte autour du ticket, les conversations liées, les implémentations similaires, les fichiers pertinents, les décisions antérieures et les contraintes que je devrais connaître avant de toucher au code.

Cela ne supprime pas le besoin de réfléchir.

Cela supprime une grande partie de la recherche manuelle avant que la réflexion puisse commencer.

Cette différence compte. Il y a beaucoup de temps invisible en ingénierie qui n'est pas exactement du code, mais pas exactement de la planification non plus. C'est le temps passé à essayer de comprendre ce qui s'est déjà passé, ce que quelqu'un voulait dire dans un ticket, pourquoi un système fonctionne d'une certaine manière, ou si ce que vous allez construire existe déjà sous un autre nom.

L'IA est très douée pour réduire cette friction.

Elle peut résumer de longs fils de discussion. Elle peut expliquer des chemins de code inconnus. Elle peut comparer des approches. Elle peut aider à transformer un contexte éparpillé en une première carte utilisable.

Je dois toujours vérifier la carte. Mais au moins, je ne pars pas dans la nature avec un ticket Jira et un rêve.

Quand l'exécution devient plus facile

Le changement majeur suivant, c'est l'exécution.

L'IA a rendu beaucoup plus facile le passage de « Je ne sais pas du tout par où commencer » à « J'ai un premier jet qui fonctionne ».

Ce premier jet peut être l'implémentation d'une fonctionnalité, un test, une requête de base de données, un script, une migration, un dashboard Splunk ou un changement lié à AWS. Il peut relever du front-end, du back-end, de l'infrastructure, de l'observabilité, ou d'une combinaison bancale de tout cela, parce que le logiciel a de l'humour.

Cela a changé le type de travail que je peux prendre en charge.

Le full-stack paraît plus accessible. L'infrastructure fait moins peur. Les migrations sont plus faciles à raisonner. Les dashboards, les requêtes et les systèmes inconnus ne sont plus des murs à escalader avant de pouvoir avancer.

L'IA ne vous donne pas magiquement de l'expertise. Mais elle peut raccourcir la distance entre être bloqué et être utile.

Cela a été particulièrement précieux pour moi, qui ai commencé dans le front-end et ai évolué vers un full-stack plus large. Avant, passer dans un nouveau domaine impliquait souvent de passer longtemps à apprendre simplement le vocabulaire du problème. Maintenant, je peux poser de meilleures questions plus tôt. J'obtiens des exemples plus vite. Je peux générer une première version, l'inspecter, la contester et en apprendre quelque chose.

La courbe d'apprentissage est toujours là.

L'IA la rend simplement moins solitaire.

Les tests en sont un bon exemple. Je ne veux pas que cet article devienne une lettre d'amour aux tests, car ce serait suspect. Mais l'IA a rendu les tests plus rapides à écrire et plus faciles à déboguer. Elle peut générer des mocks, suggérer des cas auxquels je n'aurais pas pensé, mettre à jour des tests existants et aider à raisonner sur les échecs.

Je dois toujours m'assurer que les tests ont du sens. Une suite de tests qui passe n'est utile que si elle teste le bon comportement. Mais l'IA a accéléré la mécanique, ce qui me laisse plus de place pour réfléchir à la couverture au lieu de me battre avec la forme d'un objet mock pendant la moitié d'un après-midi.

Une petite victoire, mais bien réelle.

Après le premier jet

Le problème, c'est que l'ingénierie logicielle ne s'arrête pas au premier jet.

C'est généralement là que commencent les problèmes intéressants, qui attendent tranquillement derrière une suite de tests qui passe et un assistant très sûr de lui.

C'est là que l'IA commence à me ralentir.

Une solution générée peut sembler correcte. Elle peut compiler. Elle peut passer les tests. Elle peut même être proprement écrite. Mais cela ne signifie pas automatiquement que c'est la bonne solution pour la base de code, le produit ou l'équipe.

Le modèle peut faire des hypothèses. Il peut manquer une contrainte. Il peut choisir un schéma qui paraît raisonnable isolément mais ne correspond pas au fonctionnement réel du système. Il peut résoudre un problème plus grand que celui que j'avais. Il peut introduire une abstraction qui semble élégante aujourd'hui et superflue d'ici jeudi.

Avant l'IA, une grande partie de mon temps passait à créer la première version : chercher, lire, demander, essayer, déboguer, réécrire.

Maintenant, l'IA peut compresser radicalement cette première version.

Mais ensuite, je dois la vérifier.

Je dois lire le code généré comme je relirais le travail de quelqu'un d'autre. Je dois comprendre pourquoi il a fait certains choix. Je dois vérifier les cas limites. Je dois m'assurer que les tests ne se contentent pas de passer, mais sont utiles. Je dois confirmer que l'implémentation s'intègre à l'architecture existante. Je dois retirer les changements inutiles.

Je dois me demander s'il s'agit de la plus petite solution raisonnable, ou si l'assistant a voulu refaire la cuisine parce que je lui avais demandé de changer une ampoule.

Ce travail de relecture compte.

Si je le saute, l'IA ne me fait pas gagner de temps. Elle crée du travail futur avec une meilleure mise en forme.

Le nouveau goulot d'étranglement

L'IA déplace le temps de la création vers la vérification.

Ce peut être un bon compromis. Dans de nombreux cas, il l'est. Je préfère passer plus de temps à évaluer une solution qu'à fixer une page blanche ou à fouiller six onglets pour me rappeler quelle issue GitHub correspondait à mon message d'erreur.

Mais la vérification reste du travail.

Elle demande du jugement, du contexte et de la discipline. Elle demande de savoir à quoi ressemble le « bien ». Elle demande de comprendre le système assez bien pour décider si la solution générée y a sa place.

Le code le plus rapide à générer n'est pas toujours le plus rapide à assumer.

C'est devenu l'une des leçons les plus importantes pour moi. Si je ne peux pas expliquer le code, il ne m'appartient pas vraiment. Si je ne peux pas défendre le compromis, je ne devrais pas le livrer. Si je ne peux pas le déboguer plus tard, alors l'IA ne m'a pas fait gagner de temps. Elle a emprunté du temps au futur, et mon futur moi est rarement impressionné par cet arrangement.

C'est la partie de l'ingénierie assistée par l'IA qui paraît moins glamour que les démos.

La démo s'arrête quand le code apparaît.

Le travail continue quand quelqu'un doit le maintenir.

Trop démarrer

Il y a un autre goulot d'étranglement auquel je ne m'attendais pas : le travail en cours.

L'IA facilite le démarrage du travail. Beaucoup. Je peux explorer une idée, générer une première implémentation, créer des tests et ouvrir une PR plus vite qu'avant.

C'est puissant.

Mais démarrer un travail n'est pas la même chose que le terminer.

Quand créer du travail coûte moins cher, il devient plus facile d'en créer trop. Soudain, il y a plus de branches, plus de PR, plus de demandes de relecture, et plus de changements qui dépendent d'autres changements. Certaines PR doivent atterrir dans un ordre précis. Certaines ont besoin d'un contexte qui vit dans une autre branche. Certaines sont assez petites isolément, mais ensemble elles forment une file que l'équipe doit encore relire, comprendre et fusionner.

Le goulot d'étranglement passe de « Puis-je construire cela ? » à « Pouvons-nous l'absorber en toute sécurité ? »

L'IA peut accélérer l'exécution individuelle, mais le logiciel est toujours livré par des équipes.

Cela signifie que la coordination compte encore. La relecture compte encore. L'ordonnancement compte encore. Garder des PR petites compte encore. En fait, cela compte peut-être davantage maintenant, parce que le coût de génération de trop de travail a baissé.

C'est l'un des effets les plus étranges de l'IA. Elle peut me donner l'impression d'être plus productif tout en créant davantage de travail inachevé autour de moi.

Plus de mouvement n'est pas toujours plus de progrès.

Parfois, le progrès, c'est des PR plus petites, un ordonnancement plus clair, moins de branches en parallèle, et assez de discipline pour finir ce que j'ai déjà commencé avant de demander à l'IA de m'aider à en commencer trois autres.

Ce qui a réellement changé

L'IA me fait gagner du temps quand elle m'aide à trouver du contexte, à synthétiser des informations, à échafauder une solution ou à exécuter la première version du travail.

C'est aussi la version de l'IA qui correspond le mieux à ce que nous construisons chez Webflow : une IA connectée à de vrais workflows, à de vraies surfaces produit et à de vrais systèmes de publication. La valeur n'est pas seulement qu'un assistant peut générer quelque chose rapidement. La valeur est qu'il peut aider les gens à passer du contexte à la création puis à la livraison avec moins de charge manuelle, tout en laissant de la place au jugement et à la responsabilité humains.

Elle me ralentit quand la partie difficile n'est plus de produire du code, mais de le vérifier, de l'ordonnancer, de le relire et de l'assumer.

Ce compromis en vaut la peine.

Je suis bien plus rapide avec l'IA que sans. Je peux travailler sur davantage de zones de la stack. Je me débloque plus vite. Je peux construire des choses qui m'auraient pris beaucoup plus de temps auparavant. Je passe moins de temps à chasser le contexte et plus de temps à prendre des décisions.

Mais l'IA n'a pas supprimé les parties difficiles de l'ingénierie.

Elle les a déplacées.

Le travail consiste moins à partir d'une page blanche et davantage à savoir à quoi ressemble le « bien ». Moins à assembler manuellement chaque élément de contexte et davantage à valider que le tableau assemblé est correct. Moins à taper soi-même chaque ligne et davantage à assumer chaque ligne que l'on livre.

C'est la version de l'IA en ingénierie qui me paraît réelle.

Pas de la magie. Pas un remplaçant. Pas un raccourci pour contourner le jugement.

Un assistant très rapide qui me fait gagner beaucoup de temps, à condition de me souvenir que je reste l'ingénieur responsable du résultat.