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é.
Je 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 de mon système n’a rien eu de technique. Elle a consisté à découper une activité qui n’en avait pas en jalons, en tâches et en livrables. Sans ce découpage, aucun outil n’aurait rien mesuré : il aurait seulement stocké. Aucune assistance ne fait ce travail-là à ta place, 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. Mon système devait être utilisable par des personnes qui ne sont pas informaticiennes. Cette seule contrainte a décidé de tout le reste : renoncer à la complexité, y compris à des fonctions que j’aurais su faire et qui auraient rendu l’outil plus riche et moins utilisé. Une assistance qui code ne t’aidera pas à renoncer. Elle te proposera 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.
Le problème n’était pas de produire l’information. C’était de choisir ce qu’il fallait 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 d’ingénieur, corrigée avec 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.