La lecture de cet article fait immédiatement penser aux « logiciels » mis en place par le CNRS pour gérer les missions de ses personnels. Mêmes causes, mêmes effets. Administratifs qu'il faut former, qui doivent décupler le temps imparti à ce travail, et qui s'arrachent les cheveux, personnel qui doit renoncer aux missions. Les similitudes sont si fortes, qu'on ne peut se penser d'imaginer que ce qui paraissait des erreurs de développement, ne soit en fait bien dans le cahier des charges.
On ne compte plus les logiciels commandés par l'État et réalisés par un de nos fleurons informatique (Cap Gemini, Atos, …) qui se vautrent complètement à l'usage (avec en plus, souvent, un déni des décideurs face aux réclamations des utilisateurs). Il n'y a jamais eu de rapports de la Cour des Comptes sur ce sujet ?
Je doute qu'il s'agisse uniquement de ratages imputables aux prestataires.
Si si il y a eu des rapports mais visiblement «L'État ne peut pas s'en passer.» J'aimerais bien moi aussi pouvoir livrer un projet totalement bancale et toucher quand même quelques millions… En fait non je n'aimerais pas, c'est du vol, suis pas un voleur. Mais c'est tout de même hallucinant de se faire payer rubis sur l'ongle pour des trucs qui ne fonctionnent pas. Je me demande si c'est pareil dans d'autres industries, genre livrer un avion qui ne vole que si il fait beau ou un train qui roule mais à 20km/h max.
Posté par mahikeulbody .
Évalué à 7 (+5/-0).
Dernière modification le 15 septembre 2025 à 14:40.
Là, tu parles des cas où le logiciel ne marche pas comme demandé. Moi je pensais aux cas où ce qui est demandé ne correspond pas aux besoins des utilisateurs.
Loin de moi l'idée de minimiser ce scandale, mais, en matière de comptabilité, tu peux avoir des logiciels très mal fichus. J'en veux pour preuve celui, en ligne et d'origine américaine, d'un cabinet d'expertise comptable tellement mal fichu que même les gens du cabinet avaient du mal à l'utiliser. Je te dis pas les clients censés faire leur compta dessus (d'accord il y aurait gros à redire sur le choix par ce cabinet d'un logiciel américain pour une entreprise française quand il y a un large choix de logiciels mieux adaptés aux règles de la comptabilité française, et à son vocabulaire).
Posté par arnaudus .
Évalué à 9 (+6/-0).
Dernière modification le 15 septembre 2025 à 16:22.
Je doute qu'il s'agisse uniquement de ratages imputables aux prestataires.
Ça m'étonnerait qu'il y ait une cause unique, mais il semble impossible de sortir de tels logiciels si le cahier des charges était bien fait. Un des problèmes est que les règles à implémenter dans ce genre de logiciels sont souvent absurdes et incohérentes (parce que fonction publique). Par exemple, une validation par un n+1 alors que tout le monde n'a pas de n+1. Quand c'était géré à la main, un agent prenait l'habitude de forcer la validation quand la situation l'exigeait, sans que les grands pontes sachent que cette situation existait. Donc évidemment, quand la règle est implémentée sans cette connaissance, bah le système devient complètement grippé.
En fait, plus concrètement, les règles de gestion dans la fonction publique sont fixées par la loi et par ses décrets d'application. Dans n'importe quelle structure privée, quand on s'aperçoit que le logiciel n'arrive pas à gérer une situation, on va modifier légèrement les règles pour que ça passe. Mais c'est totalement impossible dans la fonction publique car une telle décision mettrait celui qui la prend sous la menace d'une sanction; si la règle dit que les facturettes papier doivent être collectées et stockées après avoir été scannées, les reçus électroniques vont devoir être imprimés, stockés, et les versions papier de ces reçus imprimés vont devoir être re-scannés pour rentrer dans le système. Tout le monde est conscient que c'est débile, mais personne n'a le pouvoir de changer.
Les prestataires ne sont pas payés pour vérifier la cohérence des règles. On leur file un cahier des charges absurdes, avec des gros trucs bloquants à chaque étape (genre validation du changement du jour de télétravail par le président de la République dont le cahier des charges fournit l'adresse email en dur), ils les implémentent, et après ça ne fonctionne pas, évidemment. Ils doivent bien se marrer (ou pleurer quand ils comprennent que c'est leurs impôts qui partent en fumée).
« Dans n'importe quelle structure privée, quand on s'aperçoit que le logiciel n'arrive pas à gérer une situation, on va modifier légèrement les règles pour que ça passe. Mais c'est totalement impossible[.] »
Sur le principe, vous avez certainement plutôt raison. Mais j'ai souvenir que, lorsque mon épouse travaillait à tester les logiciels de la CAF, il arrivait occasionnellement que les tests mettent en évidence des discordances entre les possibilité de la réalité et les logiques des textes officiels. Et dans ces cas, il advenait que, à l'instar des portes avions américains, ce soit le législateur, ou le pouvoir exécutif qui revoit sa copie. Donc non, pas totalement impossible, juste absolument inenvisageable.
Je suis d'accord, ça n'est pas techniquement impossible, mais il faut juste 15 ans et des milliers d'heures de travail, une volonté politique forte, l'implication de gens compétents… C'est quand même un repoussoir.
Les catastrophes logicielles ne font que démontrer que ces incohérences peuvent être gérées par des humains, mais pas par des algorithmes. Un exemple frappant est le logiciel de paye des armées, qui n'a en réalité jamais fonctionné.
La raison pour laquelle le prestataire accepte de passer ces outils en prod m'échappe, par contre. Il faut forcément la complicité des incapables qui ont établi le cahier des charges, qui doivent sentir que ça va chauffer pour leurs fesses si quelqu'un s'intéresse à la raison pour laquelle le prestataire ne livre pas à temps. Mais rien n'est pire que de passer en prod un logiciel qui ne passe pas les tests, qui peut s'imaginer que ça va bien se passer? Sauf à partir à la retraite dans le mois qui suit, on doit bien se douter que ça va remonter, non?
Oui, mise en prod trop rapide, mais l'explication me semble simple : trop de retard accumulé. Dans l'exemple d'Op@le, il fallait faire vite car tous les ministères ont évolués, la réglementation aussi. Il était nécessaire d'avoir un outil s'interfaçant avec d'autre systèmes de l’État.
Or,l’Éducation Nationale s'est endormi avec ses vielles appli pendant 20 ans… Du coup il fallait faire vite.
Le boulot aurait pu être fait 10 ans plus tôt (cela s'est fait dans les universités)
Est-ce vraiment utile de le préciser ? Si oui, rappelons également que les poules n'ont que très exceptionnellement des dents (ou alors, elles sont très très anciennes) et que les cochons ne volent quasiment qu'en avion, contrairement à E. Musk qui lui plane souvent plus haut que ses fusées, qui ne permettront pas la colonisation de Mars :-).
on réduit le nombre de dossiers traités par jour, on réduit le nombre de sorties scolaires …. En plus de ça on fait fuir les fonctionnaires qui ont à travailler dessus. C'est donc pas un bug, c'est une feature.
Et il faut plus de monde pour réaliser la même tâche. Ça crée donc de l'emploi qualifié. Idéal dans une société ou l'on a confondu l'objectif d'améliorer la formation avec celui du nombre de diplômés ! Quelques semaines de formations, et hop des bac+5 qui trouvent enfin des fonctions à la mesure des compétences acquises.
Pour l'instant, les dépenses ont augmentées pour redresser la barre. Et effet positif, des enquêtes ont été menées (Sénat, inspection générale), qui confortent au contraire le besoin de personnels dans les services.
Utilisateur d'Op@le, je vois dans cet article la rengaine de personnes ancrées dans le passé avec le confort de la parfaite connaissance des anciennes applis conçus dans les années 90.
Ce n'est pas CapGemini qui a conçus le progiciel. CapGemini a œuvré (mal) à l'adaptation d'une solution de l'éditeur Cegid au besoin de l’Éducation Nationale. Quand à :
Op@le durcit l’application des règles de gestion budgétaire et comptable
la suite de la phrase dans le rapport est
,ce qui avait été recommandé par différents rapports de l’inspection générale des finances (IGF) et de l’inspection générale de l’éducation nationale et de la recherche
Ce n'est donc pas une remarque négative, car Op@le répond au besoin de sécurisation des transactions et ça, à part des personnes mal intentionnées, on ne peut le reprocher.
Op@le est perfectible, notamment sur l'ergonomie et l'interface. Il semble clairement fait pour respecter les réglementations, mais pas faciliter la vie des utilisateurs. Ceci dit… la majorité des agents ne retourneraient jamais en arrière.
Nous partions d'un logiciel maison où les échanges de données se faisaient par clé usb/courriel/papier. Un logiciel avec lequel nous devions fonctionner de manière asynchrone (export/import de fichier entre établissement et agence comptable) et imprimer en duplicata, voire triplicata les actes administratifs. Bref, pour ma part, la misère… Les techno de développement de l'ancien logiciel ne permettaient pas son évolution.
Op@le, c'est un système centralisé, sécurisé (par ex. accès nominatif, pas le cas avant) et permettant le travail synchrone et collaboratif. Moderne quoi… Bémol, pas de client lourd mais interface web. L'ergonomie du logiciel est lié à ce fait. Le multi-fenêtrage dans un navigateur web, c'est vraiment pas top. T'as pas de souris, tu peux pas bosser ;-)
Perso, je suis un utilisateur d'Op@le et loin de devenir fou. Au contraire, je gagne du temps, je ne gaspille plus de papier et les étapes des processus financier et comptable sont sécurisés.
La où le bas blesse, c'est le déploiement pitoyable. Il y a eut 9 vagues de déploiement depuis 2021 (sur 10, la 10e sera en janvier 2026). Chaque vague étant constituée d'un certain nombre d'établissements. Pour les premières (V2 me concernant), nous devions être des précurseurs censés former les autres. En fait nous avons été bêta testeurs. Logiciel non abouti avec des problèmes de fiabilité, formation inexistante. Bref, nous avons ramé. Et le pire c'est que nous n'avons pas ramé au même rythme sur le territoire. Avec des académies mettant les moyens pour développer la formations et créer des groupes de formateurs et d'autres où la FOAD avec des diapo à gogo étaient les seules ressources. (Scenari me fait rêver, si seulement j'avais du temps)
Les utilisateurs et les orga. syndicales ont mis la pression et devant l'évidence du fiasco, des moyens ont été débloqués par le ministère. Les cellules de support ont été renforcées, les équipes des DSI de proximité réorganisées et des comités de pilotage comprenant des utilisateurs mis en place. Bon an, mal an, Op@le s'est amélioré sur la fiabilité et quelques évolutions demandés par les utilisateurs voient le jour.
En fait Op@le était pensé pour automatiser un maximum de processus (rue de Grenelle, ils devaient imaginer des économies de personnels à la base). Problème, un collège ou un lycée, c'est pas une entreprise. Nous gérons des élèves avec tous leur environnement (parents, profs,projets éducatifs variés,…) et, nous n'utilisons pas de procédé industriel pour cela. De fait, l'intervention humaine dans le logiciel est incontournable. De plus, la décentralisation fait que tous les établissements ne fonctionnent pas de la même façon selon le département ou la région où ils sont implantés. Par exemple, un département va mettre en place un logiciel de gestion de la cantine (commandes, stock, traçabilité,etc), encore faut-il qu'il soit interfaçable avec Op@le pour payer les factures…(à ce jour aucune solution n'est prête pour ça)
Aujourd'hui, reste surtout une ergonomie moisie et non intuitive contre laquelle nous devons nous battre. Et notre plus grand problème… les problèmes RH. Quand des postes ne sont pas occupés pendant plusieurs semaines, que nous basculons d'un logiciel à l'autre à marche forcée, ben les bahuts ils ont des séquelles. Et vu que personne ne veux venir bosser chez nous*, c'est pas anecdotique.
Bref, Op@le est moderne, mais:
- il n'a pas été pensé avec ses utilisateurs
- il n'a pas été testé correctement avant passage à l'échelle
- il n'a pas été déployé correctement (trop vite, sans coordination sur le territoire)
- il rajoute aux difficultés des bahuts manquant de personnels.
- il fonctionne tout de même grâce à l'engagement des personnels qui ont développés entraide et partage (sans doute l'effet le plus inattendu par l'institution)
Au final, nous sommes fatigués, mais certainement pas fou!
*la folie, c'est peut-être d'aller au boulot pour un salaire inadéquat et des perspectives de retraite merdique.
Si je comprends bien, le constat est très mitigé, mais pas aussi négatif que le laisse entendre l’article ?
L’information n’étant évoquée nulle part, par atavisme, je me permet d’ajouter ce qui me semble être tout de même le plus gros point négatif, même si c’est un point en forme d’interrogation : le logiciel n’est pas libre ; les services de l’état n’ont pas la possibilité de le faire évoluer, en particulier pour amender les points inventoriés par vous, ou d’autres ultérieurement ?
Si c’est le cas, je trouve ça à la fois très banal — tous les services de l’état semblent procéder ainsi, vu de la où je suis — mais absolument confondant alors que nous sommes en 2025, que les problématiques privatrices sont largement connues, et que même sous payés et mal employés, nombre d’agents publics ont les compétences pour faire évoluer un logiciel.
Oui, c'est exactement ça, mitigé. Selon l'endroit, le contexte, cela passe plus ou moins bien. L'article dépeint un tableau vraiment trop noir.
Effectivement, solution privée et fermée. Ce qui implique que sans prestataire, évolutions et corrections impossibles.
Meme les exports de données sont au format excel, difficilement exploitable avec libreoffice (tableau croisé dynamique mal fichu)
Question de non utilisateur encore : est-ce qu'un passage par pandas ne permettrais pas de transposer correctement les dits tableaux croisés dynamiques vers le format ods ?
Juste pour donner le contexte de cette question, chez nous, en physique (simulation), Python, c'est ça :
du coup j'imagine, probablement naïvement, que dans tous les domaines, les développeurs en font de petits miracles ; qui sait, au point de pallier les avanies de crosoft ?
Il est sûrement possible d'améliorer ces fichiers. J'ai souvent pensé faire un modèle ods plus présentable qui importe les données de ces fichiers, mais je n'en trouve pas le temps pour l'instant.
# Bogue ?
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 4 (+2/-0).
La lecture de cet article fait immédiatement penser aux « logiciels » mis en place par le CNRS pour gérer les missions de ses personnels. Mêmes causes, mêmes effets. Administratifs qu'il faut former, qui doivent décupler le temps imparti à ce travail, et qui s'arrachent les cheveux, personnel qui doit renoncer aux missions. Les similitudes sont si fortes, qu'on ne peut se penser d'imaginer que ce qui paraissait des erreurs de développement, ne soit en fait bien dans le cahier des charges.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Bogue ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 6 (+3/-0).
Dans le cahier des quoi?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bogue ?
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 6 (+4/-0).
Le fameux cahier décharge, bien entendu :-).
Un moment j'ai cru avoir oublier aussi ce mollah.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Bogue ?
Posté par bubar🦥 . Évalué à 2 (+0/-1).
Regarde ta fiche de paie pour comprendre
# souci systémique ?
Posté par mahikeulbody . Évalué à 10 (+9/-0).
On ne compte plus les logiciels commandés par l'État et réalisés par un de nos fleurons informatique (Cap Gemini, Atos, …) qui se vautrent complètement à l'usage (avec en plus, souvent, un déni des décideurs face aux réclamations des utilisateurs). Il n'y a jamais eu de rapports de la Cour des Comptes sur ce sujet ?
Je doute qu'il s'agisse uniquement de ratages imputables aux prestataires.
[^] # Re: souci systémique ?
Posté par Faya . Évalué à 8 (+6/-0).
Si si il y a eu des rapports mais visiblement «L'État ne peut pas s'en passer.» J'aimerais bien moi aussi pouvoir livrer un projet totalement bancale et toucher quand même quelques millions… En fait non je n'aimerais pas, c'est du vol, suis pas un voleur. Mais c'est tout de même hallucinant de se faire payer rubis sur l'ongle pour des trucs qui ne fonctionnent pas. Je me demande si c'est pareil dans d'autres industries, genre livrer un avion qui ne vole que si il fait beau ou un train qui roule mais à 20km/h max.
[^] # Re: souci systémique ?
Posté par mahikeulbody . Évalué à 7 (+5/-0). Dernière modification le 15 septembre 2025 à 14:40.
Là, tu parles des cas où le logiciel ne marche pas comme demandé. Moi je pensais aux cas où ce qui est demandé ne correspond pas aux besoins des utilisateurs.
[^] # Re: souci systémique ?
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 5 (+2/-0).
Loin de moi l'idée de minimiser ce scandale, mais, en matière de comptabilité, tu peux avoir des logiciels très mal fichus. J'en veux pour preuve celui, en ligne et d'origine américaine, d'un cabinet d'expertise comptable tellement mal fichu que même les gens du cabinet avaient du mal à l'utiliser. Je te dis pas les clients censés faire leur compta dessus (d'accord il y aurait gros à redire sur le choix par ce cabinet d'un logiciel américain pour une entreprise française quand il y a un large choix de logiciels mieux adaptés aux règles de la comptabilité française, et à son vocabulaire).
Je n’ai aucun avis sur systemd
[^] # Re: souci systémique ?
Posté par arnaudus . Évalué à 9 (+6/-0). Dernière modification le 15 septembre 2025 à 16:22.
Ça m'étonnerait qu'il y ait une cause unique, mais il semble impossible de sortir de tels logiciels si le cahier des charges était bien fait. Un des problèmes est que les règles à implémenter dans ce genre de logiciels sont souvent absurdes et incohérentes (parce que fonction publique). Par exemple, une validation par un n+1 alors que tout le monde n'a pas de n+1. Quand c'était géré à la main, un agent prenait l'habitude de forcer la validation quand la situation l'exigeait, sans que les grands pontes sachent que cette situation existait. Donc évidemment, quand la règle est implémentée sans cette connaissance, bah le système devient complètement grippé.
En fait, plus concrètement, les règles de gestion dans la fonction publique sont fixées par la loi et par ses décrets d'application. Dans n'importe quelle structure privée, quand on s'aperçoit que le logiciel n'arrive pas à gérer une situation, on va modifier légèrement les règles pour que ça passe. Mais c'est totalement impossible dans la fonction publique car une telle décision mettrait celui qui la prend sous la menace d'une sanction; si la règle dit que les facturettes papier doivent être collectées et stockées après avoir été scannées, les reçus électroniques vont devoir être imprimés, stockés, et les versions papier de ces reçus imprimés vont devoir être re-scannés pour rentrer dans le système. Tout le monde est conscient que c'est débile, mais personne n'a le pouvoir de changer.
Les prestataires ne sont pas payés pour vérifier la cohérence des règles. On leur file un cahier des charges absurdes, avec des gros trucs bloquants à chaque étape (genre validation du changement du jour de télétravail par le président de la République dont le cahier des charges fournit l'adresse email en dur), ils les implémentent, et après ça ne fonctionne pas, évidemment. Ils doivent bien se marrer (ou pleurer quand ils comprennent que c'est leurs impôts qui partent en fumée).
[^] # Re: souci systémique ?
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 6 (+4/-0).
Sur le principe, vous avez certainement plutôt raison. Mais j'ai souvenir que, lorsque mon épouse travaillait à tester les logiciels de la CAF, il arrivait occasionnellement que les tests mettent en évidence des discordances entre les possibilité de la réalité et les logiques des textes officiels. Et dans ces cas, il advenait que, à l'instar des portes avions américains, ce soit le législateur, ou le pouvoir exécutif qui revoit sa copie. Donc non, pas totalement impossible, juste absolument inenvisageable.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: souci systémique ?
Posté par arnaudus . Évalué à 6 (+4/-1).
Je suis d'accord, ça n'est pas techniquement impossible, mais il faut juste 15 ans et des milliers d'heures de travail, une volonté politique forte, l'implication de gens compétents… C'est quand même un repoussoir.
Les catastrophes logicielles ne font que démontrer que ces incohérences peuvent être gérées par des humains, mais pas par des algorithmes. Un exemple frappant est le logiciel de paye des armées, qui n'a en réalité jamais fonctionné.
La raison pour laquelle le prestataire accepte de passer ces outils en prod m'échappe, par contre. Il faut forcément la complicité des incapables qui ont établi le cahier des charges, qui doivent sentir que ça va chauffer pour leurs fesses si quelqu'un s'intéresse à la raison pour laquelle le prestataire ne livre pas à temps. Mais rien n'est pire que de passer en prod un logiciel qui ne passe pas les tests, qui peut s'imaginer que ça va bien se passer? Sauf à partir à la retraite dans le mois qui suit, on doit bien se douter que ça va remonter, non?
[^] # Re: souci systémique ?
Posté par bertile . Évalué à 3 (+2/-0).
Oui, mise en prod trop rapide, mais l'explication me semble simple : trop de retard accumulé. Dans l'exemple d'Op@le, il fallait faire vite car tous les ministères ont évolués, la réglementation aussi. Il était nécessaire d'avoir un outil s'interfaçant avec d'autre systèmes de l’État.
Or,l’Éducation Nationale s'est endormi avec ses vielles appli pendant 20 ans… Du coup il fallait faire vite.
Le boulot aurait pu être fait 10 ans plus tôt (cela s'est fait dans les universités)
[^] # Re: souci systémique ?
Posté par tkr (Mastodon) . Évalué à 2 (+0/-0).
https://en.wikipedia.org/wiki/Lighthouse_and_naval_vessel_urban_legend
[^] # Re: souci systémique ?
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 2 (+0/-0).
Est-ce vraiment utile de le préciser ? Si oui, rappelons également que les poules n'ont que très exceptionnellement des dents (ou alors, elles sont très très anciennes) et que les cochons ne volent quasiment qu'en avion, contrairement à E. Musk qui lui plane souvent plus haut que ses fusées, qui ne permettront pas la colonisation de Mars :-).
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
# Un moyen de faire des économies ....
Posté par totof2000 . Évalué à 4 (+2/-0).
on réduit le nombre de dossiers traités par jour, on réduit le nombre de sorties scolaires …. En plus de ça on fait fuir les fonctionnaires qui ont à travailler dessus. C'est donc pas un bug, c'est une feature.
[^] # Re: Un moyen de faire des économies ....
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 3 (+1/-0).
Et il faut plus de monde pour réaliser la même tâche. Ça crée donc de l'emploi qualifié. Idéal dans une société ou l'on a confondu l'objectif d'améliorer la formation avec celui du nombre de diplômés ! Quelques semaines de formations, et hop des bac+5 qui trouvent enfin des fonctions à la mesure des compétences acquises.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Un moyen de faire des économies ....
Posté par bertile . Évalué à 2 (+1/-0).
Pour l'instant, les dépenses ont augmentées pour redresser la barre. Et effet positif, des enquêtes ont été menées (Sénat, inspection générale), qui confortent au contraire le besoin de personnels dans les services.
# Fou, non, je crois pas.
Posté par bertile . Évalué à 10 (+20/-0).
Utilisateur d'Op@le, je vois dans cet article la rengaine de personnes ancrées dans le passé avec le confort de la parfaite connaissance des anciennes applis conçus dans les années 90.
Ce n'est pas CapGemini qui a conçus le progiciel. CapGemini a œuvré (mal) à l'adaptation d'une solution de l'éditeur Cegid au besoin de l’Éducation Nationale. Quand à :
la suite de la phrase dans le rapport est
Ce n'est donc pas une remarque négative, car Op@le répond au besoin de sécurisation des transactions et ça, à part des personnes mal intentionnées, on ne peut le reprocher.
Op@le est perfectible, notamment sur l'ergonomie et l'interface. Il semble clairement fait pour respecter les réglementations, mais pas faciliter la vie des utilisateurs. Ceci dit… la majorité des agents ne retourneraient jamais en arrière.
Nous partions d'un logiciel maison où les échanges de données se faisaient par clé usb/courriel/papier. Un logiciel avec lequel nous devions fonctionner de manière asynchrone (export/import de fichier entre établissement et agence comptable) et imprimer en duplicata, voire triplicata les actes administratifs. Bref, pour ma part, la misère… Les techno de développement de l'ancien logiciel ne permettaient pas son évolution.
Op@le, c'est un système centralisé, sécurisé (par ex. accès nominatif, pas le cas avant) et permettant le travail synchrone et collaboratif. Moderne quoi… Bémol, pas de client lourd mais interface web. L'ergonomie du logiciel est lié à ce fait. Le multi-fenêtrage dans un navigateur web, c'est vraiment pas top. T'as pas de souris, tu peux pas bosser ;-)
Perso, je suis un utilisateur d'Op@le et loin de devenir fou. Au contraire, je gagne du temps, je ne gaspille plus de papier et les étapes des processus financier et comptable sont sécurisés.
La où le bas blesse, c'est le déploiement pitoyable. Il y a eut 9 vagues de déploiement depuis 2021 (sur 10, la 10e sera en janvier 2026). Chaque vague étant constituée d'un certain nombre d'établissements. Pour les premières (V2 me concernant), nous devions être des précurseurs censés former les autres. En fait nous avons été bêta testeurs. Logiciel non abouti avec des problèmes de fiabilité, formation inexistante. Bref, nous avons ramé. Et le pire c'est que nous n'avons pas ramé au même rythme sur le territoire. Avec des académies mettant les moyens pour développer la formations et créer des groupes de formateurs et d'autres où la FOAD avec des diapo à gogo étaient les seules ressources. (Scenari me fait rêver, si seulement j'avais du temps)
Les utilisateurs et les orga. syndicales ont mis la pression et devant l'évidence du fiasco, des moyens ont été débloqués par le ministère. Les cellules de support ont été renforcées, les équipes des DSI de proximité réorganisées et des comités de pilotage comprenant des utilisateurs mis en place. Bon an, mal an, Op@le s'est amélioré sur la fiabilité et quelques évolutions demandés par les utilisateurs voient le jour.
En fait Op@le était pensé pour automatiser un maximum de processus (rue de Grenelle, ils devaient imaginer des économies de personnels à la base). Problème, un collège ou un lycée, c'est pas une entreprise. Nous gérons des élèves avec tous leur environnement (parents, profs,projets éducatifs variés,…) et, nous n'utilisons pas de procédé industriel pour cela. De fait, l'intervention humaine dans le logiciel est incontournable. De plus, la décentralisation fait que tous les établissements ne fonctionnent pas de la même façon selon le département ou la région où ils sont implantés. Par exemple, un département va mettre en place un logiciel de gestion de la cantine (commandes, stock, traçabilité,etc), encore faut-il qu'il soit interfaçable avec Op@le pour payer les factures…(à ce jour aucune solution n'est prête pour ça)
Aujourd'hui, reste surtout une ergonomie moisie et non intuitive contre laquelle nous devons nous battre. Et notre plus grand problème… les problèmes RH. Quand des postes ne sont pas occupés pendant plusieurs semaines, que nous basculons d'un logiciel à l'autre à marche forcée, ben les bahuts ils ont des séquelles. Et vu que personne ne veux venir bosser chez nous*, c'est pas anecdotique.
Bref, Op@le est moderne, mais:
- il n'a pas été pensé avec ses utilisateurs
- il n'a pas été testé correctement avant passage à l'échelle
- il n'a pas été déployé correctement (trop vite, sans coordination sur le territoire)
- il rajoute aux difficultés des bahuts manquant de personnels.
- il fonctionne tout de même grâce à l'engagement des personnels qui ont développés entraide et partage (sans doute l'effet le plus inattendu par l'institution)
Au final, nous sommes fatigués, mais certainement pas fou!
*la folie, c'est peut-être d'aller au boulot pour un salaire inadéquat et des perspectives de retraite merdique.
[^] # Re: Fou, non, je crois pas.
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 7 (+5/-0).
Si je comprends bien, le constat est très mitigé, mais pas aussi négatif que le laisse entendre l’article ?
L’information n’étant évoquée nulle part, par atavisme, je me permet d’ajouter ce qui me semble être tout de même le plus gros point négatif, même si c’est un point en forme d’interrogation : le logiciel n’est pas libre ; les services de l’état n’ont pas la possibilité de le faire évoluer, en particulier pour amender les points inventoriés par vous, ou d’autres ultérieurement ?
Si c’est le cas, je trouve ça à la fois très banal — tous les services de l’état semblent procéder ainsi, vu de la où je suis — mais absolument confondant alors que nous sommes en 2025, que les problématiques privatrices sont largement connues, et que même sous payés et mal employés, nombre d’agents publics ont les compétences pour faire évoluer un logiciel.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Fou, non, je crois pas.
Posté par bertile . Évalué à 6 (+5/-0).
Oui, c'est exactement ça, mitigé. Selon l'endroit, le contexte, cela passe plus ou moins bien. L'article dépeint un tableau vraiment trop noir.
Effectivement, solution privée et fermée. Ce qui implique que sans prestataire, évolutions et corrections impossibles.
Meme les exports de données sont au format excel, difficilement exploitable avec libreoffice (tableau croisé dynamique mal fichu)
[^] # Re: Fou, non, je crois pas.
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 4 (+2/-0).
Question de non utilisateur encore : est-ce qu'un passage par pandas ne permettrais pas de transposer correctement les dits tableaux croisés dynamiques vers le format ods ?
Juste pour donner le contexte de cette question, chez nous, en physique (simulation), Python, c'est ça :
du coup j'imagine, probablement naïvement, que dans tous les domaines, les développeurs en font de petits miracles ; qui sait, au point de pallier les avanies de crosoft ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Fou, non, je crois pas.
Posté par bertile . Évalué à 1 (+0/-0).
Il est sûrement possible d'améliorer ces fichiers. J'ai souvent pensé faire un modèle ods plus présentable qui importe les données de ces fichiers, mais je n'en trouve pas le temps pour l'instant.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.