Lorsque j’ai terminé ma formation de Data Scientist, Streamlit était l’outil que j’utilisais presque naturellement pour présenter mes travaux.
Et il faut reconnaître qu’il remplit très bien son rôle.
En quelques lignes de Python, on peut afficher un modèle, des métriques, des graphiques ou des tableaux et construire rapidement une interface suffisante pour démontrer qu’un projet fonctionne.
Mais ma frustration est arrivée très tôt.
Je trouvais l’outil facile à prendre en main, mais trop limité dès que je voulais modeler davantage l’interface : menus, boutons, tableaux, parcours ou identité visuelle.
Puis j’ai commencé mes premières missions.
Et j’ai découvert qu’une interface n’était pas seulement l’endroit où l’on affiche le résultat d’un modèle.
Quand un développeur Web pense autrement
Dès ma première mission, je me suis retrouvé à travailler avec un développeur Web full-stack.
La différence m’a sauté aux yeux.
Ce n’était pas seulement qu’il savait produire quelque chose de beaucoup plus joli.
Il pensait spontanément à des choses auxquelles, en tant que développeur Machine Learning, je pensais beaucoup moins : navigation, rôles utilisateur et administrateur, états de l’application, messages d’erreur, parcours utilisateur ou sécurisation des données.
Je pensais principalement au moteur.
Il pensait au produit.
Nous avons alors abandonné Streamlit au profit de deux interfaces Web : l’une pour les utilisateurs, l’autre pour superviser le système.
Cette séparation a changé ma manière de voir les interfaces. Elles n’étaient plus seulement la couche finale ajoutée autour d’un modèle ; elles pouvaient influencer la façon même dont le système devait être conçu.
Une interface peut aussi être un outil d’ingénierie
L’interface administrateur m’a particulièrement marqué.
Mon besoin était très concret : éviter de devoir rechercher en permanence les informations nécessaires à la supervision dans différents fichiers, consoles ou services.
Je voulais pouvoir retrouver plus facilement les logs, les métriques, les modèles utilisés, certains paramètres, les données entrantes, les scores, les retours utilisateurs, la relance de traitements ou encore les éléments de traçabilité.
Tout n’était évidemment pas toujours intégré, car une bonne interface de supervision demande elle aussi du temps de développement.
Mais lorsqu’elle était bien pensée, elle simplifiait considérablement mon propre travail de Machine Learning.
L’UI n’était alors plus seulement destinée à rendre le produit agréable pour son utilisateur final.
Elle devenait également un instrument de pilotage.
C’est probablement à ce moment-là que j’ai commencé à comprendre que la frontière entre le front-end et mon propre travail était moins nette que je ne le pensais.
Un choix d’interface peut imposer de nouvelles données, nécessiter un nouvel endpoint, obliger à enregistrer une métrique ou modifier la manière dont nous stockons certains événements.
L’interface ne vient donc pas toujours après l’architecture. Elle peut aussi contribuer à la définir.
Pourquoi WordPress ?
Je n’ai pas décidé un matin de devenir développeur Web.
Et je ne cherche toujours pas à le devenir au sens où un spécialiste full-stack peut l’être.
Une opportunité professionnelle concrète autour de WordPress m’a simplement donné une raison supplémentaire d’aller comprendre sérieusement cet environnement.
La société concernée travaille avec WordPress.
Il m’a donc semblé naturel de ne pas attendre le premier jour pour découvrir comment tout cela fonctionne.
Et puisque j’avais justement besoin de construire mon propre portfolio, l’exercice était idéal.
Je préfère généralement apprendre en réalisant quelque chose dont j’ai réellement besoin.
C’est ainsi que Zang.AI est progressivement devenu mon laboratoire.
D’abord HTML.
Puis CSS.
Puis JavaScript.
Et progressivement PHP et WordPress.
Je ne sais pas jusqu’où j’irai dans cet apprentissage.
Ce n’est d’ailleurs pas tellement mon objectif.
Je souhaite surtout avoir suffisamment fait le tour du sujet pour être productif rapidement : comprendre un site existant, modifier ce qui doit l’être, diagnostiquer un problème, comprendre un plugin, connecter un service et dialoguer correctement avec les développeurs.
Ensuite, j’apprendrai en avançant.
Trois fichiers et beaucoup de choses qui deviennent moins mystérieuses
L’une des découvertes les plus simples m’a pourtant beaucoup plu.
Dans la première version statique de mon portfolio, je travaille principalement avec trois fichiers :
index.html
styles.css?v=1.0.0
script.js?v=1.0.0
Je les vois presque comme trois conteneurs reliés, chacun avec son propre langage et sa propre responsabilité.
HTML construit la structure.
CSS organise la présentation.
JavaScript ajoute le comportement.
Le Web réel devient rapidement beaucoup plus complexe, mais cette séparation m’a permis de démystifier ce que je regardais auparavant comme un bloc unique.
Un bouton n’est plus seulement « un bouton sur une page » : je peux comprendre ce qui le construit, le dessine, déclenche son comportement et appelle ensuite un service.
Et cette compréhension change aussi ma manière de penser mes propres systèmes IA.
L’interface revient vers l’architecture
Dans mes premiers projets, le mouvement naturel était souvent :
modèle → API → interface
Le modèle fonctionnait.
Nous l’exposions.
Puis quelqu’un construisait l’interface.
Aujourd’hui, je vois beaucoup mieux le mouvement inverse :
interface → besoin → données → API → architecture
Si l’utilisateur doit suivre l’état d’un traitement, nous devons exposer cet état.
S’il doit comprendre pourquoi une réponse a été produite, nous devons conserver suffisamment de traçabilité.
S’il doit pouvoir corriger une décision, nous devons prévoir comment cette correction sera enregistrée puis réutilisée.
S’il existe plusieurs rôles, nous devons réfléchir aux autorisations.
Le front-end finit donc par poser des questions au back-end.
Et parfois, ces questions remontent jusqu’au modèle lui-même.
C’est exactement ce que j’avais déjà découvert dans mon projet RAG juridique : attendre la fin pour réfléchir à l’interface peut conduire à devoir revoir une partie de la chaîne.
Le Web ne m’éloigne donc pas vraiment de la Data ou de l’IA.
Il me donne plutôt une meilleure vision de ce qui se passe autour.
Et Streamlit dans tout cela ?
Je n’ai aucune envie de transformer Streamlit en mauvais outil simplement parce que j’apprends autre chose.
Ce serait contraire à toute ma manière de travailler.
Si demain une mission interne peut être correctement réalisée avec Streamlit, je l’utiliserai volontiers.
Pourquoi construire davantage ?
Et si un développeur full-stack prend en charge l’expérience utilisateur, je peux rester concentré sur la Data, les modèles et les APIs.
En revanche, lorsqu’aucun développeur Web n’est prévu et que l’interface doit devenir un vrai produit, WordPress fait désormais partie des premières solutions que j’aurai envie d’étudier.
Pas automatiquement.
Mais naturellement.
Si le besoin dépasse ce que WordPress sait faire proprement, il faudra utiliser autre chose.
L’outil doit rester au service du besoin, pas l’inverse.
Déléguer le code sans déléguer la compréhension
Les LLM peuvent aujourd’hui produire une part croissante du code à partir d’instructions bien dirigées.
Je trouve cela formidable, mais cela ne réduit pas l’importance de comprendre ce que le code fait.
Au contraire.
Si je délègue davantage l’écriture, je dois être encore plus clair sur ce que je souhaite obtenir, savoir relire la logique générale, tester le résultat et assumer ce qui sera mis en production.
C’est une forme d’abandon conscient assez proche de celle que j’applique aux systèmes IA eux-mêmes.
Je n’ai pas besoin d’écrire personnellement chaque ligne pour en prendre la responsabilité, mais je dois comprendre suffisamment le système pour savoir ce que je lui demande et reconnaître lorsqu’il dérive.
Et si je me trompais ?
Un ingénieur Machine Learning peut parfaitement faire un excellent travail sans devenir développeur Web.
Il est impossible d’être spécialiste de tout, et un développeur full-stack expérimenté fera naturellement mieux et plus vite que moi sur de nombreux sujets.
Je ne cherche donc pas à remplacer cette compétence, mais à mieux dialoguer avec elle, à comprendre ses contraintes et à construire seul lorsque le besoin reste raisonnable.
Surtout, je ne veux plus considérer l’interface comme une boîte noire dans laquelle viendra se déposer mon modèle une fois le « vrai travail » terminé.
Apprendre une technologie ne signifie pas nécessairement vouloir changer de métier.
Cela peut simplement permettre de mieux comprendre tout ce qui se passe autour du métier que nous avons déjà choisi.
Je ne sais pas jusqu’où WordPress me mènera.
Mais je sais pourquoi j’ai commencé.
Mes modèles finiront toujours, d’une manière ou d’une autre, par rencontrer un humain.
Et si cet humain utilise le produit à travers une interface, une question reste ouverte :
à partir de quel moment cette interface cesse-t-elle d’être une simple façade pour devenir une partie du système lui-même ?