Le remote a changé le cadre du travail. L’IA en change déjà la nature.
J’ai déjà vécu une première bascule quand j’ai transformé mon entreprise en full remote. À l’époque, il a fallu repenser l’organisation, le management, la coordination et la confiance. Le sujet était visible : on changeait le cadre du travail.
Avec l’IA, le mouvement me paraît différent. Il est moins visible, mais probablement plus profond. Depuis deux ans, nous l’utilisons déjà dans notre quotidien, pour la documentation, l’analyse, la synthèse ou encore le support au code. Au départ, je la voyais surtout comme une couche d’assistance : utile, parfois impressionnante, parfois inégale. Puis un cap a été franchi.
Le jour où nous avons mis en production du code issu de notre propre système interne de développement assisté par l’IA, j’ai compris que nous n’étions plus simplement en train d’ajouter un outil. Nous commencions à changer notre manière de produire. C’est comme cela que je comprends aujourd’hui l’AI-first : non pas comme un slogan ou comme l’idée de “mettre de l’IA partout”, mais comme une question beaucoup plus concrète. Que doit changer une entreprise quand l’IA devient une composante centrale du fonctionnement de l’entreprise
Dans mon cas, la réponse se cristallise autour de deux sujets : la connaissance et la production.
La connaissance
S’il y a un problème que je vois depuis vingt ans dans mon métier, c’est celui de la connaissance qui part avec les gens. Dans l’IT, surtout sur des applications complexes, un développeur met parfois six mois à vraiment monter en compétence. Il doit comprendre le métier, les exceptions, l’historique, les attentes implicites et les zones sensibles. Puis, parfois, deux ans plus tard, il n’est plus là.
Ce n’est pas un reproche. C’est la réalité du marché. Mais pour l’entreprise, c’est une fuite silencieuse et permanente.
Pour l’entreprise, cela signifie une chose très concrète : on recommence sans cesse à reconstruire une partie de ce qu’on avait déjà appris.
Je l’ai vu dans les départs, dans les besoins de backup, dans les astreintes et dans les imprévus, quand les bonnes personnes ne sont pas disponibles. Sur le papier, la connaissance existe : documents, mails, tickets, PV, specs. Dans la vraie vie, elle est souvent dispersée, incomplète, difficile à retrouver, parfois obsolète.
C’est pour cela que je veux bâtir ce que j’appelle une Smart Base, c’est-à-dire une base de connaissance vivante, structurée et exploitable.
L’idée n’est pas de stocker plus, mais de perdre moins. Et pour cela, il faut aussi changer de discipline. Ce qui compte doit laisser une trace utile : une décision explicite, un ticket propre, une note de cadrage, un livrable bien documenté.
Plus le travail est formalisé dans des documents, des enregistrements et des livrables partageables, plus la connaissance cesse d’être individuelle pour devenir collective.
La production
L’autre sujet m’est venu d’une pression très concrète : le marché.
Les clients veulent aller toujours plus vite, livrer plus vite, corriger plus vite, décider plus vite. Dans notre métier, la vitesse n’est plus un confort, c’est une exigence. Mais accélérer est facile à demander et difficile à faire bien. Quand on accélère mal, on dégrade la qualité, on crée de la dette, on documente moins bien, et on paie plus tard ce qu’on croit gagner tout de suite.
Le marché nous demande d’aller plus vite, mais il ne nous pardonnera pas d’aller plus vite en livrant moins bien. C’est là que l’IA devient intéressante.
Dans nos premiers essais, elle nous a parfois fait gagner beaucoup de temps, parfois peu. Cela dépend fortement de la complexité, du contexte et du cadrage. Mais il y avait un autre effet, plus intéressant encore : quand on prend le temps de bien faire les choses, l’IA peut aussi améliorer la qualité. Elle nous oblige à mieux cadrer, mieux contextualiser, mieux formaliser et mieux relire. Autrement dit, elle ne change pas seulement la vitesse ; elle change déjà notre discipline de production.
C’est ce qui m’amène aujourd’hui à intégrer l’IA de façon beaucoup plus structurée dans notre manière de produire. L’idée n’est plus seulement d’utiliser un assistant de code ici ou là, mais de faire entrer progressivement notre propre workflow de développement (analyse, développement, qualité, CI/CD, mise en production) dans un système coordonné par plusieurs agents (une forme d’usine logicielle agentique).
Nous entrons ainsi dans une autre manière de développer : moins centrée sur l’écriture manuelle du code à chaque étape, davantage sur un développement guidé par l’IA, mais piloté par l’humain. Je ne parle pas ici de remplacer les développeurs ni de fantasmer une automatisation totale. Je parle d’une production plus homogène, plus traçable, plus documentée et plus guidée.
L’humain reste central, mais son rôle évolue. Le développeur ne disparaît pas ; il change de centre de gravité. Il devient moins seulement producteur de code et davantage orchestrateur, cadreur et superviseur. Le métier reste profondément technique, mais la valeur se déplace vers la capacité à contextualiser, arbitrer, contrôler et fiabiliser.
Ce que j’en retiens
Je ne vois plus l’AI-first comme une mode. Je le vois comme un déplacement concret : mieux garder ce que l’entreprise apprend et mieux structurer la manière dont elle produit.
Après le full remote, nous sommes en train de faire entrer notre entreprise dans une nouvelle étape : devenir réellement Remote & AI-First. C’est ma vision de l’entreprise de demain. Peut-être pas pour tous les business. Mais je suis convaincu que de plus en plus de nouvelles entreprises naîtront directement Remote & AI-native.
Pour moi, c’est là que se dessine une partie de l’entreprise contemporaine. Et ce modèle, nous ne sommes plus seulement en train de le penser. Nous sommes en train de le construire !