De l’effet waouh à la réalité : ce que l’IA a changé dans ma façon d’apprendre et de construire

Tout en étant professionnel dans l’informatique et la Data, je suis avant tout passionné de technologie et, quelque part, toujours « ingénieur informaticien ».

Je me suis rapproché du métier et du management au fil de ma carrière, mais j’ai toujours gardé un lien très fort avec la compréhension et la construction de tout ce que je touche dans l’informatique.

Quand je choisis une stack technique, ce n’est pas seulement parce que tout le monde l’utilise ou qu’on m’a dit que c’était la meilleure. C’est aussi parce que j’ai passé du temps à la comprendre. À savoir à quoi elle sert, quelles sont ses forces et, surtout, ses faiblesses !

Quand j’ai commencé, ne serait-ce qu’installer une base de données pour faire des tests en local et apprendre était une vraie galère.

Des heures de documentation, de discussions avec les « anciens » qui s’étaient déjà cassé les dents avant nous… et tout ça pour quoi ?

Juste pour apprendre à faire du SELECT, du CROSS JOIN, du ROLLUP ou encore du GROUP BY CUBE, ma préférée de toutes !

Et que dire de la création d’une application web ou de l’hébergement d’un site « simple » ?

Il y avait toujours moyen de payer pour un service tout fait. Mais pour un ingénieur qui cherche à comprendre, ça pouvait vite devenir très long.

Aujourd’hui, n’importe qui peut ouvrir son outil d’IA et, en quelques phrases parfois même mal formulées, réaliser l’application de ses rêves.

J’ai fait comme tout le monde.

Et franchement, la première fois, c’est incroyable.

Ces derniers mois, j’ai beaucoup expérimenté avec ces nouveaux outils. J’ai généré des centaines, puis des milliers de lignes de code, construit de petites applications, des automatisations, testé différentes méthodes et différentes approches.

J’étais vraiment époustouflé.

Et je n’ai pas un avis très différent de la grande majorité d’entre nous : notre façon de développer est en train de changer à une vitesse incroyable.

Et puis, après avoir créé plein de nouvelles choses, j’ai voulu reprendre certains projets pour les améliorer.

Et c’est vraiment là que les choses sont devenues intéressantes.

1. L’effet waouh : construire presque sans construire

Ma première réaction face aux nouveaux outils de développement assistés par IA a probablement été la même que celle de beaucoup de développeurs.

Waouh.

On décrit ce qu’on veut, mais « à peu près correctement », vu qu’on y a réfléchi quelques minutes tout en faisant la cuisine.

L’IA crée les fichiers, installe les dépendances, construit l’interface, ajoute quelques composants et finit par produire quelque chose qui ressemble réellement à une application.

Et moi ?

J’ai juste cliqué sur « Autoriser cette fois » à maintes reprises, parce que je n’avais pas forcément envie de laisser mon IA contrôler totalement mon ordinateur…

Et ça fonctionne !

Ce n’est pas parfait.

Ce n’est pas exactement comme je l’imaginais.

Mais j’étais content !

En quelques prompts et quelques tokens, j’avais quelque chose qui m’aurait pris des heures, des jours, voire des semaines.

Surtout quand on n’a plus 20 ans, qu’il faut s’occuper d’une famille et qu’on essaie de bricoler ça dans une soirée, après le repas des enfants et avant le film du soir avec madame.

Quand on a connu les heures et les heures passées ne serait-ce qu’à installer les outils et à réussir un premier « Hello World », c’est assez déstabilisant.

Naturellement, le réflexe est alors de pousser un peu plus loin.

Ajoute-moi cette fonctionnalité.

Puis :

Ajoute aussi ça.

Et on assemble.

On empile.

On rajoute des tas de fonctionnalités qu’on n’aurait même pas commencé à toucher dans notre monde d’avant.

On aurait probablement mis ça dans un backlog d’idées, juste pour ne pas oublier, avec l’espoir d’y revenir un jour.

Peut-être.

Et ça, c’est vraiment l’un des changements les plus incroyables que l’IA peut apporter.

On peut tester une idée sans forcément investir plusieurs jours dedans.

Et ça, je trouve ça réellement révolutionnaire.

Mais il y a un piège.

2. Ça fonctionne… jusqu’au jour où il faut comprendre pourquoi

Sur mes premiers projets, j’ai fait comme bon nombre d’entre nous.

J’ai laissé l’IA construire à ma place.

J’ai demandé de faire, d’améliorer, de changer, de rajouter… et je regardais surtout le résultat final.

Un bug ? → Un prompt pour corriger.

Une anomalie ? → Un prompt.

Une fonction qui ne fonctionne pas ? → Un prompt.

Et globalement, on dépense des tokens, on épuise ses quotas, mais on arrive à ses fins.

C’est un bonheur.

Et puis, comme je suis quand même « développeur », « ingénieur », j’ai voulu intégrer moi-même une fonctionnalité et faire une petite modification à la main.

Et là…

Je ne savais même pas par où commencer.

J’avais une application qui marchait plutôt bien… mais que je ne connaissais absolument pas.

Pourquoi cette librairie ?

Pourquoi cette structure de dossiers ?

Pourquoi cette logique se trouve ici ?

Pourquoi deux composants font quasiment la même chose ?

Pourquoi cette dépendance a-t-elle été ajoutée alors qu’on aurait pu faire beaucoup plus simple ?

Ce que je regardais n’était pas particulièrement mauvais.

Le problème était ailleurs.

Je n’avais pas participé aux décisions qui avaient construit le logiciel.

J’avais validé le résultat, mais pas le chemin qui permettait d’y arriver.

Et plus le projet grossissait, plus chaque nouveau prompt ajoutait une petite couche supplémentaire à quelque chose que je maîtrisais de moins en moins.

Avec l’IA, on crée une nouvelle forme de dette technique.

Une dette qu’on ne voit pas tout de suite, parce que l’application fonctionne.

Mais le jour où il faut comprendre, modifier, déboguer ou simplement expliquer le système à quelqu’un d’autre, elle devient beaucoup plus présente.

Ça m’a fait réaliser quelque chose d’assez simple, qui me semblait pourtant naturel dans mon travail au quotidien :

produire du code et construire un logiciel sont deux choses totalement différentes.

Quand j’ai commencé dans la BI, les rôles étaient beaucoup moins spécialisés qu’aujourd’hui.

Le même développeur pouvait faire de l’intégration de données, de la modélisation, de l’analyse, construire des rapports et parfois même s’occuper du déploiement ou de l’exploitation. Même quand on travaillait en équipe, chacun touchait un peu à tout.

Aujourd’hui, ce périmètre est souvent réparti entre plusieurs profils : Data Engineer, Data Architect, Data Analyst, Data Scientist, DataOps… chacun avec un rôle beaucoup plus précis.

Cette spécialisation a évidemment énormément de qualités.

Mais elle change aussi la manière de travailler.

Quand on devait construire une chaîne complète soi-même, réfléchir à l’architecture avant de coder était presque une nécessité. Il fallait comprendre où l’on allait, comment les différentes briques allaient s’articuler et quelles décisions prises à un endroit allaient avoir des conséquences ailleurs.

Aujourd’hui, un Data Engineer peut très bien travailler dans un cadre déjà défini par un architecte. Il peut donc produire un excellent code sans forcément avoir besoin de remettre en question l’architecture globale à chaque ligne.

Dans mon parcours, cette séparation était beaucoup moins marquée. J’ai appris à construire et à architecturer en même temps, simplement parce que j’avais besoin des deux pour avancer.

C’est probablement aussi pour ça que laisser l’IA prendre toutes les décisions à ma place m’a autant dérangé.

L’IA est devenue incroyablement bonne pour produire du code.

Pour construire, il faut toujours réfléchir.

3. Reprendre le contrôle : construire avec l’IA, pas lui demander de construire à ma place

J’ai donc essayé de changer ma façon de travailler avec l’IA.

Et c’est exactement ce que j’ai essayé de faire avec Nice Data.

L’objectif n’était pas de donner un prompt du genre :

Fais-moi une plateforme pour publier des articles autour de la Data.

Techniquement, j’aurais probablement obtenu quelque chose qui tienne la route.

Mais cette fois, j’ai essayé de faire l’inverse.

D’abord réfléchir au besoin.

Qu’est-ce que je veux réellement construire ?

Quelles sont les différentes briques ?

Qu’est-ce qui doit rester simple ?

Qu’est-ce que je veux pouvoir maintenir moi-même ?

Qu’est-ce qui mérite d’être développé et qu’est-ce qui existe déjà très bien ailleurs ?

Comment est-ce que je veux héberger tout ça ?

Comment les différentes parties doivent-elles communiquer ?

Et seulement ensuite utiliser l’IA pour m’aider à construire.

En bref, reprendre un flux et une méthode presque « à l’ancienne », mais en étant sérieusement augmenté par l’IA.

La différence peut sembler subtile, mais elle change complètement la manière de travailler avec cet outil.

Je ne demande plus simplement :

Construis ça.

J’ai davantage l’impression d’avoir un partenaire à côté de moi.

Un partenaire qui réfléchit et produit souvent beaucoup plus vite que moi, mais auquel il faut donner des tâches précises.

Je peux lui demander de proposer plutôt que de décider.

De refactoriser.

De m’expliquer.

D’analyser une solution.

Ou, évidemment, de prendre en charge une tâche chronophage et un peu pénible, sans grande implication architecturale.

Mais les choix importants restent discutés et validés par moi.

Je veux comprendre pourquoi on intègre cette librairie.

Pourquoi on utilise ce composant.

Pourquoi on organise le projet de cette façon.

En gros, l’IA est un accélérateur incroyable.

Mais elle ne remplace pas le besoin de savoir ce que l’on est en train de construire.

4. Plus l’IA permet d’aller vite, plus l’architecture devient importante

C’est justement le paradoxe qui m’intéresse le plus aujourd’hui.

Puisqu’on peut générer du code et demander à l’IA de comprendre très facilement un repository ou une application entière, on pourrait penser qu’elle saura toujours se débrouiller pour trouver une solution.

Et j’ai plutôt l’impression que c’est exactement l’inverse.

Quand écrire cent lignes de code prend du temps, il existe naturellement une sorte de friction.

On réfléchit un minimum avant de les écrire.

Quand produire ces mêmes cent lignes ne coûte quasiment plus rien, cette friction disparaît.

On peut générer une nouvelle abstraction.

Ajouter une nouvelle librairie.

Créer un nouveau service.

Modifier complètement une partie de l’application.

Puis recommencer dix minutes plus tard.

La vitesse de production augmente énormément.

Mais notre capacité à comprendre un système, elle, n’a pas été multipliée par dix.

Et je pense que c’est là que notre rôle commence à changer.

Savoir écrire chaque ligne de code reste utile.

Mais savoir prendre du recul devient encore plus important.

Comprendre les composants.

Définir les responsabilités.

Choisir les bonnes abstractions.

Éviter une complexité inutile.

Savoir dire non à une solution techniquement séduisante mais disproportionnée.

Et parfois simplement rappeler à l’IA :

Non. On va faire plus simple.

Finalement, ce sont des problématiques que l’on connaît déjà très bien dans la Data.

On peut empiler des notebooks, ajouter des pipelines, multiplier les transformations et construire très rapidement quelque chose qui fonctionne.

Puis découvrir quelques mois plus tard que personne n’ose plus y toucher.

L’IA ne fait qu’accélérer ce phénomène.

Elle permet de construire beaucoup plus.

Elle permet donc aussi de construire beaucoup plus rapidement des choses difficiles à maintenir.

Ou même parfois totalement inutiles.

La vraie question n’est peut-être plus seulement :

Est-ce que je peux construire ça ?

Mais plutôt :

Est-ce que je vais encore comprendre ce que j’ai construit dans six mois ?

5. Construire, comprendre… et surtout continuer à explorer

Tout cela pourrait donner l’impression que je suis devenu méfiant vis-à-vis de l’IA.

Et c’est exactement l’inverse.

Je n’ai probablement jamais eu autant envie d’expérimenter.

Parce qu’une quantité énorme de choses qui étaient devenues trop chronophages dans ma vie quotidienne, trop longues, trop éloignées de mes compétences ou simplement pas assez importantes pour justifier plusieurs jours de travail deviennent maintenant accessibles.

Un outil peut être testé dans la journée.

Une technologie que je connais mal devient beaucoup plus facile à explorer.

Je peux travailler sur du développement web, revenir sur du Python, essayer une stack Data open source, creuser dbt, automatiser certaines tâches autour de Fabric ou construire mes propres outils.

Pas parce que je suis soudain devenu expert de tout.

Mais parce que la barrière entre :

J’aimerais comprendre comment ça marche.

et :

Je vais essayer.

s’est considérablement réduite.

Et c’est probablement ce qui me donne envie de recommencer à écrire.

Pas pour commenter chaque nouveau modèle ou chaque annonce autour de l’IA.

Des tas de gens le font déjà.

Mais plutôt pour documenter ce que je construis, ce que je comprends et ce que je découvre en chemin.

Je partage déjà beaucoup oralement avec mes collègues de travail ou lors des apéros organisés à Nice via Meetup.

Mais je me rends compte que plus j’expérimente vite, plus j’oublie vite.

Un peu comme quand on scrolle sur son téléphone pour « tuer le temps » : on peut expérimenter tellement rapidement qu’on ne retient finalement pas grand-chose.

Et je trouve que la phase d’écriture et de partage permet justement de corriger ça.

Pourquoi avais-je choisi cette approche ?

Pourquoi n’avait-elle finalement pas fonctionné ?

Quelle était la petite subtilité qui m’avait fait perdre deux heures ?

Est-ce que cette technologie était réellement intéressante ou simplement séduisante pendant la démo ?

Écrire permet de garder une trace.

Et le fait de devoir expliquer quelque chose oblige aussi à vérifier qu’on l’a réellement compris.

C’est un peu l’idée derrière la renaissance de Nice Data.

Construire. Comprendre. Explorer.

Il y aura probablement beaucoup de Data Engineering, parce que c’est mon métier.

Du Microsoft Fabric, parce que c’est une plateforme sur laquelle je travaille au quotidien.

Mais aussi du dbt, du Python, des architectures Data, du développement, des stacks open source, des outils autour de l’IA et probablement quelques expérimentations difficiles à classer.

L’objectif n’est pas d’avoir toujours raison du premier coup.

Au contraire.

J’ai plutôt envie de documenter le chemin entre le moment où quelque chose semble génial… et celui où on commence réellement à comprendre ce qu’on peut en faire, jusqu’à son application réelle en production.

Parce qu’en ce moment, avec l’IA, ce chemin est particulièrement intéressant.

Je ne promets pas deux articles par semaine pendant les dix prochaines années.

Mais l’idée est de partager un bout du chemin ensemble, le plus régulièrement possible.

PS : si vous passez par la magnifique ville de Nice, n’hésitez pas à venir me rencontrer lors des Meetups du Club Data !