J'ai construit une application de pilotage sans être développeur. Ce n'est pas une prouesse, et ce n'est pas non plus la démonstration que « n'importe qui peut coder maintenant ». C'est plus intéressant que ça, et plus limité.
IAJe vais commencer par le fait, parce qu’il est vérifiable et qu’il porte tout le reste : je ne suis pas développeur de formation. J’ai conçu un système de pilotage, je l’ai cadré, et je l’ai construit avec l’assistance d’outils d’intelligence artificielle. Trois mois entre la première ligne et la première utilisation réelle. Seul, en dehors du temps de travail. Des centaines d’itérations.
Je le dis parce que c’est vrai, et parce que la conclusion qu’on en tire d’habitude est fausse.
Ce que ça change
Le code n’est plus le verrou.
Il l’a été longtemps. Quelqu’un qui avait une idée d’outil et pas de compétence technique avait deux options : payer, ou renoncer. Les deux coûtaient cher, la première en argent, la seconde en idées mortes. C’est cette barrière-là qui est tombée, et il ne faut pas en minimiser la portée : elle décidait de qui pouvait construire.
Concrètement, dans mon travail, ça veut dire qu’entre « il faudrait un outil qui fasse ça » et un écran qui le fait, il n’y a plus de mois d’attente ni de budget à défendre. Il y a un essai, et on le fait tout de suite. Et comme un essai ne coûte presque rien, on essaie, y compris des choses qu’on n’aurait jamais osé demander à un prestataire, parce qu’on n’était pas sûr d’en avoir besoin.
Ce que ça ne change pas
Tout le reste. Et « tout le reste » est la plus grosse part du travail.
La première décision du système n’a rien eu de technique. Il a fallu découper en jalons, en tâches et en livrables une activité qui n’avait aucune structure. Sans ce découpage, l’outil n’aurait rien mesuré. Il aurait stocké, c’est tout. Aucune assistance ne fait ce travail-là, parce qu’il ne demande pas de savoir écrire du code : il demande de connaître le métier qu’on outille.
Ce qui décide aujourd’hui de la réussite d’un projet numérique n’est plus la capacité à écrire du code. C’est de savoir quoi construire, pour qui, et ce qu’on peut se permettre d’abandonner.
Cette dernière partie est celle qu’on sous-estime le plus. Le système devait servir à des personnes qui ne sont pas férues d’informatique. Cette seule contrainte a tout décidé : renoncer à la complexité, y compris à des fonctions faisables, qui auraient rendu l’outil plus poussé, plus abouti. Mais d’une prise en main plus complexe. Une assistance qui code n’aide pas à renoncer. Elle propose même le contraire : elle ajoute volontiers.
Le défaut qui m’a le plus appris
Mon générateur de rapports fonctionnait. Il produisait des informations sans pertinence pour la hiérarchie, dans une mise en page qui desservait le contenu.
Produire l’information n’était pas le problème. Le problème, c’était de choisir quoi retirer, et pour qui. Un rapport n’est pas un déversement de données, c’est un message adressé à quelqu’un de précis. Une erreur de concepteur, corrigée par un réflexe de communicant.
Aucun outil ne m’aurait signalé ce défaut. Il ne se voit pas dans le code : il se voit sur le visage de celui qui lit le rapport.
Ce que j’en fais
Je ne recommande à personne de « se mettre à construire ses outils avec l’IA ». Je constate que la question a changé de place. Elle n’est plus est-ce que je sais faire ? mais est-ce que je sais ce qu’il faut faire, et pour qui ?
La deuxième question est plus difficile que la première. Elle l’a toujours été. Simplement, avant, on ne s’y heurtait pas : on s’arrêtait avant.