Op@le confort : je ne sais pas coder, mais j’avais une idée...

Je ne sais pas coder, mais j’avais une idée

Tout est parti d’un constat assez banal : je passe beaucoup de temps dans Op@le. Vraiment beaucoup. Et, comme probablement beaucoup de collègues qui utilisent quotidiennement l’application, il m’arrive régulièrement de me dire : Ce serait quand même mieux si… .

Si cette zone prenait moins de place. Si cette information ressortait davantage. Si cette fenêtre utilisait réellement les 49 pouces de mon écran [1]. Si je pouvais masquer ce dont je ne me sers jamais. Si certaines informations pouvaient être regroupées au même endroit plutôt que de devoir jouer continuellement avec les ascenseurs. Et puis en septembre 2026 la version J2 arrive, avec une ergonomie qui se dégrade encore un peu…

Rien qui justifie de réécrire Op@le, donc. Mais suffisamment d’irritants pour finir par se poser une question : ne pourrait-on pas adapter un peu l’outil à son utilisateur plutôt que de toujours adapter l’utilisateur à l’outil ? Le problème, évidemment, c’est que je ne suis pas développeur et que la réponse officielle est plutôt lente. Enfin… c’était le problème.

Op@le est une application web, profitons en !

On l’oublie facilement tant nous l’utilisons comme un logiciel métier, mais Op@le est une application web. Elle fonctionne dans notre navigateur et repose donc sur les mêmes grandes technologies que les autres applications web.

Sans entrer dans un cours de développement, trois briques sont intéressantes à connaître. Le HTML décrit ce qui se trouve dans une page. Le CSS détermine la manière dont ces éléments sont présentés. JavaScript permet notamment de rendre la page interactive.

C’est surtout le deuxième qui m’intéresse ici. Le CSS — Cascading Style Sheets, ou feuilles de style en cascade — définit une bonne partie de l’apparence d’une page : largeur d’un bloc, taille d’un texte, espacement, couleur, positionnement, affichage ou non de certains éléments, etc. Or, lorsque nous utilisons Op@le, notre navigateur reçoit une page et doit l’afficher. Il est possible de lui ajouter nos propres règles de présentation et de lui dire, en substance : affiche bien Op@le, mais présente-moi cette partie-là autrement.

C’est ce principe qui est à l’origine de mon projet. Et une précision importante s’impose immédiatement : on ne modifie pas Op@le.

Une feuille CSS appliquée par le navigateur ne vient évidemment pas réécrire l’application sur les serveurs de l’administration. Elle ne modifie ni la base de données, ni une écriture comptable, ni les traitements réalisés par Op@le. Elle agit localement, sur notre poste, au moment où le navigateur affiche la page. Pour reprendre une comparaison plus proche de nos métiers : on ne touche pas à la comptabilité, on change simplement la présentation de l’outil qui permet de la consulter. Cela donne déjà un terrain d’expérimentation assez large.

C’est finalement à ce stade que le sujet devient, à mon sens, beaucoup plus intéressant que la seule modification de l’apparence d’Op@le. J’ai une idée assez précise de ce que je voudrais obtenir. Je sais identifier ce qui me gêne dans mon usage quotidien et ce qui pourrait être amélioré. En revanche, je serais bien incapable, seul, d’identifier correctement l’élément d’une page puis d’écrire la règle CSS correspondante sans risquer de transformer trois autres écrans en œuvre d’art — ou pas.

Il y a encore quelques années, j’aurais donc eu deux solutions : apprendre sérieusement le développement web ou abandonner l’idée et continuer à traiter mes écritures en ayant mal aux yeux. Aujourd’hui, une troisième solution existe : demander à quelqu’un qui sait coder. Et ce quelqu’un peut être une intelligence artificielle.

C’est là que la répartition des rôles devient intéressante. Une IA connaît HTML, CSS, JavaScript, Python et quantité d’autres langages dont j’ignorais parfois jusqu’à l’existence. En revanche, elle ne connaît pas mon métier. Elle ne sait pas pourquoi telle information est importante pour un agent comptable ou un secrétaire général. Elle ne sait pas pourquoi telle zone consultée cinquante fois par jour mérite d’être immédiatement accessible ou pourquoi un écran qui paraît parfaitement cohérent à sa conception peut devenir pénible lorsqu’on l’utilise toute la journée. Moi, j’ai l’impression que si.

Je peux donc lui expliquer mon besoin : cette zone prend trop de place ; je voudrais conserver ces trois informations, masquer celles-ci et présenter le reste sur une seule ligne. L’IA se charge alors de traduire cette demande en code. Je teste. Ce n’est pas exactement ce que j’avais demandé. Je précise. Elle corrige. Je teste à nouveau. Cela fonctionne ici mais pose un problème ailleurs. On reprend. Et ainsi de suite. Au passage, on apprend.

À force de voir revenir les mêmes termes, je finis par comprendre ce qu’est un sélecteur CSS, je découvre le code derrière une page web, et je comprends progressivement pourquoi telle règle fonctionne dans un écran et pas dans un autre. Puis viennent d’autres notions. Ce qui ressemblait au départ à un langage totalement hermétique commence à devenir un peu plus logique.

Je ne suis toujours pas développeur, loin de là. Mais je comprends mieux ce que l’IA fabrique et je suis donc progressivement capable de mieux la piloter. Surtout, je commence à voir lorsqu’elle raconte une ânerie. Et il y en a !

Quitte à utiliser l’IA, regardons ce que propose la DINUM

Lorsque l’on parle d’intelligence artificielle générative, le premier réflexe est généralement de penser à ChatPGT, Claude, Gemini ou aux autres services commerciaux désormais bien connus. Pour les agents publics, nous disposons pourtant aujourd’hui d’une offre portée par la DINUM qui mérite réellement d’être regardée.

Espac’EPLE avait d’ailleurs proposé un webinaire sur le sujet des outils de la DINUM, et je suis friand de ces outils. J’utilise aujourd’hui régulièrement Assistant et Transcripts dans mon établissement. Pour prendre un exemple très concret, les comptes rendus de réunion qui nécessitaient auparavant beaucoup de temps peuvent désormais être préparés à partir d’une transcription, puis relus et corrigés. En matière de temps gagné, c’est spectaculaire. Pour notre projet, c’est toutefois Albert API qui va nous intéresser.

Dit comme cela, on commence à perdre quelques lecteurs. Pourtant, le principe n’est pas très compliqué. Avec un assistant IA classique, je peux prendre un morceau de mon fichier CSS, le copier dans une conversation, expliquer mon problème, récupérer la proposition de l’IA, la recopier dans mon fichier puis tester. Cela fonctionne très bien pour quelques lignes.

Une API permet d’aller plus loin : mon environnement de développement peut directement discuter avec le modèle d’intelligence artificielle. Il peut lui transmettre le contexte nécessaire, récupérer ses réponses et travailler directement sur les fichiers du projet.

Albert API nous permet justement d’accéder à différents modèles d’intelligence artificielle proposés dans l’environnement de la DINUM. Son interface repose en outre sur des standards largement utilisés, ce qui permet de la connecter à différents outils existants.

On passe alors progressivement d’une IA avec laquelle on discute à une IA avec laquelle on développe. Et là, les possibilités deviennent beaucoup plus intéressantes.

VS Code, Albert et le navigateur : pas besoin d’être informaticien

Pour travailler sur mes fichiers, j’utilise Visual Studio Code, généralement appelé VS Code. C’est un éditeur de code gratuit et très largement utilisé. [2]

La première ouverture, lorsque l’on n’est pas développeur, est un peu déroutante. Des fichiers à gauche, du code au milieu et un terminal en bas qui semble parfois prendre un malin plaisir à vous rappeler que vous n’avez rien à faire ici. Mais on s’y fait.

Une fois un outil d’IA relié à Albert API, je ne suis plus obligé de lui transmettre manuellement chaque morceau de code. L’IA peut parcourir le projet, retrouver le fichier concerné, comprendre comment il est organisé et proposer directement les modifications nécessaires.
La demande change donc complètement. Au lieu de lui dire écris-moi une règle CSS qui réduit la largeur de ce bloc, je peux lui dire : voilà mon projet ; cette partie de l’interface prend trop de place ; regarde comment elle est gérée et adapte-la sans casser le reste. Mais il reste une difficulté : encore faut-il que l’IA comprenne ce que je suis en train de regarder dans Op@le.

C’est là qu’interviennent les outils de développement du navigateur. Vous les avez peut-être déjà ouverts par accident en appuyant sur F12 avant de les refermer immédiatement. Ils permettent notamment d’examiner la structure d’une page web et de comprendre quelles règles déterminent l’affichage de chacun de ses éléments. Des outils permettent désormais de donner à notre assistant de développement un accès à ces informations. Il peut donc inspecter la page, identifier l’élément qui m’intéresse, examiner les règles qui lui sont appliquées puis modifier mon projet.

Concrètement, j’explique ce qui me gêne. L’IA regarde la page. Elle retrouve l’élément concerné, analyse son affichage, modifie mon CSS et je recharge Op@le pour voir le résultat.
Parfois c’est parfait. Parfois je lui réponds : non, ce n’est pas du tout ce que je voulais, et on recommence. C’est presque magique.

Et contrairement à ce que l’on pourrait imaginer, je n’ai pas eu besoin d’installer un serveur dans le local technique, de récupérer trois vieilles cartes graphiques et de passer mon week-end à apprendre Linux [3]. Un ordinateur, un navigateur, VS Code, un accès à Albert API et un outil capable de faire le lien entre tout cela suffisent pour commencer.

Pour installer tout ça, Assistant IA m’aide et me dit ce que je dois faire : installer un module avec powershell, paramétrer VS Code, utiliser la clé API d’Albert, etc. Le plus important reste finalement d’avoir une idée à tester.

Au départ, je voulais simplement modifier quelques couleurs

Les premières modifications tenaient dans quelques règles CSS. Puis, comme souvent, le projet a commencé à prendre un peu ses aises. Une règle en appelle une autre. Certaines idées sont abandonnées, d’autres corrigées. On découvre qu’une amélioration parfaitement adaptée à son écran donne un résultat beaucoup moins heureux sur celui d’un collègue. Une modification réalisée pour une transaction a parfois des conséquences inattendues sur une autre.

Le petit CSS bricolé pour mon usage personnel commence donc progressivement à devenir un projet qu’il faut organiser et tester. Et une nouvelle question arrive assez naturellement : puisque ces adaptations me sont utiles, pourquoi ne pas les partager avec d’autres collègues ?
C’est aujourd’hui la première étape du projet : une feuille CSS partagée.

L’objectif est justement de sortir de mon propre usage. Un outil développé seul répond toujours merveilleusement bien aux habitudes de celui qui l’a développé. Les autres utilisateurs sont beaucoup plus efficaces pour trouver les écrans oubliés, les mauvaises idées et les choses qui ne fonctionnent pas comme prévu.

On teste donc, on critique, on améliore. Ce qui fonctionne reste. Ce qui était une fausse bonne idée disparaît. Et de nouvelles propositions apparaissent. Mais partager un fichier CSS reste une solution de bricoleur. Il faut expliquer où le mettre, comment l’activer et comment le remplacer lorsque le projet évolue. C’est pourquoi l’étape suivante s’est rapidement imposée : en faire une extension pour le navigateur.

Le principe ne change pas. L’extension ne remplace pas Op@le, et n’intervient toujours pas dans sa base de données. Elle permet simplement au navigateur d’appliquer automatiquement les adaptations prévues lorsque nous utilisons l’application. Pour l’utilisateur, en revanche, c’est beaucoup plus simple. L’extension s’installe, peut être activée ou désactivée, permet progressivement de choisir certaines adaptations et peut surtout être mise à jour lorsque le projet évolue.

L’ambition reste modeste : il ne s’agit évidemment pas de révolutionner Op@le mais simplement de rendre un peu plus confortables les nombreuses heures que nous passons devant l’application.

Ce qui est assez amusant, c’est de regarder le chemin parcouru. Au départ : je vais juste changer deux ou trois couleurs et déplacer quelques éléments. Puis : ce serait quand même pratique de pouvoir désactiver cette modification. Ensuite : on pourrait mémoriser les préférences. Puis : il faudrait une petite interface.

Quelques temps plus tard, me voilà à découvrir qu’une extension possède un manifeste, des permissions, des numéros de version, un système de signature et un processus de validation chez Mozilla.

Garder tout de même quelques limites

Tout cela est assez enthousiasmant, mais nous travaillons avec une application financière et comptable de l’État, pas avec le site du club de l’association du bahut. Il faut donc bien distinguer les choses.

Modifier localement l’apparence d’une page avec du CSS relève de la présentation. Ajouter du JavaScript peut déjà permettre d’en modifier certains comportements. Automatiser des clics ou des saisies constitue encore une autre étape. Quant à laisser un agent d’intelligence artificielle réaliser librement des validations ou des opérations comptables, nous changeons totalement de sujet.

La frontière que je me fixe est donc assez simple : plus on se rapproche des données et des actes métier, plus on s’éloigne du terrain de jeu. Déplacer visuellement un bouton n’est pas cliquer sur ce bouton. Cliquer sur ce bouton n’est pas valider une opération. Et aucune prouesse technique ne fait disparaître notre responsabilité.

Il faut également conserver un minimum de recul sur ce que produit l’IA. Elle peut être particulièrement efficace, mais elle est aussi parfaitement capable de produire un code qui semble cohérent et qui ne fonctionne pas, de résoudre un problème pour en créer deux autres ou de vouloir modifier quinze fichiers lorsqu’il suffisait de changer trois lignes. Le développement assisté par IA ne consiste donc pas à lui demander fais-moi une extension parfaite pour Op@le, puis à partir prendre un café. Il faut expliquer, contrôler, tester, corriger et parfois revenir en arrière.

Autrement dit, il faut piloter. Pour des personnels d’intendance, le concept ne devrait finalement pas être totalement exotique.

Et finalement, le sujet n’est pas vraiment l’extension ou le CSS

C’est probablement ce que je retiens le plus de cette expérience. Il y a encore peu de temps, avoir une idée d’outil informatique signifiait généralement savoir la programmer, trouver quelqu’un capable de le faire ou laisser l’idée dans un coin. L’intelligence artificielle ne transforme évidemment pas un néophyte en développeur après trois prompts. Les vrais développeurs peuvent dormir tranquilles. En revanche, elle réduit considérablement la barrière technique qui nous empêchait parfois simplement d’essayer.

D’autres compétences deviennent alors particulièrement importantes : savoir identifier précisément un problème, expliquer ce que l’on souhaite obtenir, décomposer un projet en étapes, tester, repérer qu’un résultat est mauvais et comprendre progressivement suffisamment ce que fait l’IA pour ne pas la suivre aveuglément.

Mais surtout, il faut connaître son métier. Et sur ce point, nous sommes plutôt bien placés.
Nous passons nos journées dans nos outils. Nous savons exactement où nous perdons du temps. Nous connaissons les informations dont nous avons besoin. Et nous avons probablement tous construit un jour un fichier Excel improbable pour compenser quelque chose que notre application métier ne faisait pas comme nous le souhaitions.
Nous avons également tous prononcé un jour cette phrase : ce serait pourtant simple s’ils avaient prévu…

Aujourd’hui, il devient possible de poursuivre : Qu’à cela ne tienne, essayons de le faire. C’est finalement cela qui me semble le plus intéressant dans l’expérience. Ce CSS n’en est qu’une illustration. Le même principe peut servir à imaginer un tableau de bord, un outil d’analyse, un traitement de fichier, une petite application répondant à un besoin local ou l’automatisation d’un contrôle répétitif. J’ai d’ailleurs commencé à le faire pour exploiter les exports du progiciel. Tout ne mérite pas de devenir une application et toutes nos idées ne seront pas bonnes, mais beaucoup peuvent désormais être testées.

Nous en sommes donc encore au début. La feuille CSS va continuer à évoluer avec les retours des premiers collègues qui voudront bien la maltraiter. En parallèle, l’extension Firefox est en cours de validation et devrait, si tout se passe bien, simplifier son installation et ses futures mises à jour. Est-ce que tout cela sera réellement utile ? On verra à l’usage.

Mais l’expérience démontre déjà qu’un collègue qui ne sait pas programmer, mais qui connaît son métier et sait précisément ce qu’il veut obtenir, dispose aujourd’hui d’outils lui permettant de transformer une idée en quelque chose de concret.

Et tout cela parce qu’au départ, je voulais juste déplacer un bouton et remplacer quelques couleurs.