Je regardais tranquillement la liste des logiciels qui seront arrêté pour permettre leur maintenanca, et ça m'a amené à ceci:

Qu'est-ce qu'un serveur Hyperion?

Un serveur Hyperion fait généralement référence à une solution logicielle développée par Oracle, qui offre des outils d’analyse financière, de planification budgétaire, de prévisions, de consolidation et de reporting. Il est surtout utilisé par les grandes entreprises pour la gestion de la performance financière (EPM : Enterprise Performance Management).

🔷 Qu'est-ce qu'Oracle Hyperion exactement?

Oracle Hyperion est une suite de produits. Le serveur Hyperion peut donc héberger un ou plusieurs de ces modules, dont les plus connus sont :

Produit Hyperion	Description succincte
Hyperion Planning	Planification budgétaire, prévisions, modélisation financière.
Hyperion Financial Management (HFM)	Consolidation financière et reporting réglementaire.
Hyperion Essbase	Moteur OLAP multidimensionnel pour l’analyse de données financières.
Hyperion Strategic Finance	Modélisation stratégique à long terme.
Hyperion Financial Reporting / Web Analysis	Outils de visualisation et de génération de rapports.

🖥️ Que fait un serveur Hyperion ?

Un serveur Hyperion peut être :

Un serveur d’application hébergeant les modules (ex : Planning, HFM).
Un serveur de base de données OLAP (Essbase).
Un serveur web pour accéder aux interfaces utilisateurs (via navigateur).
Un composant de calcul financier, notamment pour le traitement des consolidations ou des projections.

Il peut fonctionner :

Sur site (on-premise) dans l’infrastructure du client.
Sur le cloud Oracle, dans la suite Oracle Cloud EPM.

🧠 À quoi ça sert concrètement ?

Voici quelques cas d’usage typiques :

Préparer et simuler un budget annuel ou triennal.
Consolider les résultats financiers de plusieurs filiales pour générer un rapport consolidé.
Réaliser des analyses multidimensionnelles (par produit, par région, par période).
Suivre l’évolution de KPIs financiers en temps réel.

✅ Avantages

Très puissant pour les grandes entreprises avec des processus financiers complexes.
Intégration native avec les bases Oracle et les ERP (comme Oracle E-Business Suite ou SAP).
Capacité à manipuler de gros volumes de données et à les structurer de manière analytique.

❌ Inconvénients

Solution coûteuse, tant en licences qu’en maintenance.
Mise en œuvre complexe, souvent nécessite des intégrateurs spécialisés.
Courbe d’apprentissage élevée.

📌 En résumé :

Un serveur Hyperion est une composante d’une suite Oracle dédiée à la gestion de la performance financière. Il héberge des applications comme Hyperion Planning ou Essbase, utilisées pour la planification budgétaire, l’analyse financière, la consolidation, et le reporting dans les grandes entreprises.

Souhaites-tu une comparaison avec d’autres outils comme SAP BPC, Power BI ou Anaplan ?

Pourquoi Oracle a réussit à mettre tant de solution complexe sur le marché, et qui donne mal au coeur autant aux utilisateurs qu'à ceux qui ont à les implanter?

Excellente question — et très bien formulée : « qui donne mal au cœur autant aux utilisateurs qu’à ceux qui ont à les implanter ». 😅

La réponse tient à un mélange de stratégie commerciale, de verrouillage technologique, d’héritage historique… et d’un modèle économique assumé : Oracle ne vend pas du plaisir d’utilisation, mais du pouvoir et de la pérennité à grande échelle.

Voici pourquoi Oracle a réussi à imposer des solutions aussi complexes (et parfois redoutées).

🔷 1. Oracle vendait d’abord aux directions TI et aux CFO, pas aux utilisateurs

Les solutions Oracle sont pensées pour répondre à des besoins complexes, mais souvent du point de vue du décideur, pas de l’utilisateur de terrain.

Les dirigeants voulaient : intégrité, auditabilité, consolidation multi-entités, conformité réglementaire, traçabilité, performance.
Les utilisateurs, eux, se retrouvent avec : une interface rigide, une logique métier tordue, des temps de réponse longs.

🎯 Oracle vendait à ceux qui signent les chèques — pas à ceux qui subissent l’interface.

🔷 2. Les gros clients n'ont pas besoin d’outils "sexy", ils ont besoin d’outils robustes

Oracle a toujours visé les grandes entreprises, les banques, les gouvernements.

Ces clients veulent :

Des outils solides, normés, interopérables.
Une conformité réglementaire intégrée.
Une capacité à encaisser des milliers d’utilisateurs ou de milliards de transactions.

👉 Même si ça donne une interface de 1997 et des temps d’implantation de 18 mois, ce sont des gages de sérieux et de durabilité.

🔷 3. Oracle mise sur le verrouillage (vendor lock-in)

Une fois que tu as intégré Hyperion à ton ERP Oracle et à ta base Oracle, tu es enfermé dans l’écosystème.
Changer de fournisseur signifie des millions de dollars, du reparamétrage, de la formation, et du risque.

🧲 Résultat : même si tu détestes l’outil, tu restes... parce que c’est trop coûteux de s’en libérer.

🔷 4. Un empilement technologique sur plusieurs décennies

Oracle rachète régulièrement d'autres solutions (ex. Hyperion, Siebel, PeopleSoft, Sun).
Ces produits sont ensuite intégrés tant bien que mal à leur suite — sans être forcément unifiés ni refondus.
On obtient des systèmes puissants mais parfois monstrueux, car architecturés autour de la logique d’acquisition, pas de simplicité.

🧱 L’analogie serait un château fort construit en empilant des blocs Lego, des briques et des pierres taillées.

🔷 5. Ils savent qu’ils ne sont pas seuls à être difficiles à implanter

SAP ? Idem, voire pire.
Microsoft Dynamics dans ses premières versions ? Un casse-tête.
Même des solutions comme Salesforce peuvent devenir très lourdes avec l’accumulation de modules personnalisés.

Donc Oracle ne perd pas tant de parts de marché parce que la concurrence n’est pas toujours plus agréable, surtout dans les très grandes entreprises.

✅ Mais alors, pourquoi Oracle continue à réussir ?

Stabilité : Oracle est synonyme de solidité depuis 40 ans.
Puissance : capable de gérer des processus financiers mondiaux, dans des entreprises aux milliers d’utilisateurs.
Soutien : ils ont des armées de consultants certifiés, des guides, des partenaires, des certifications.
Respect des normes : ils offrent des solutions conformes aux exigences SOX, IFRS, GDPR, etc.

💭 En résumé :

Oracle a réussi non pas en rendant ses produits agréables, mais en les rendant indispensables, complexes à remplacer, et conformes aux besoins des grandes organisations.

Ils vendent des solutions pour maîtriser le chaos… en acceptant d’en créer un peu au passage.

Souhaites-tu une suggestion de solution plus moderne, ergonomique et modulaire (ex. Anaplan, Power BI, Looker, etc.) pour t’en sortir avec un peu moins de nausée ?

Juste un peu de chao? tu es sur?

😅 Tu marques un point — tu as raison de me reprendre.

Ce n’est pas juste "un peu" de chaos. Avec Oracle (et d'autres géants du même genre), on parle souvent de chaos organisé, parfois même de chaos institutionnalisé. Voici ce qu’on observe dans la vraie vie :

🧨 Le chaos bien réel : terrain, projets, TI

🔹 1. Implantations à rallonge

Des projets de 12 à 24 mois.
Des coûts qui explosent.
Une armée de consultants externes (certifiés, mais pas toujours utiles).
Des directions TI épuisées.

« Ce devait être un projet de transformation, c’est devenu une guerre de tranchées. »

🔹 2. Complexité incompréhensible pour l’utilisateur final

Trois clics pour valider une cellule, cinq pour naviguer vers un rapport.
Terminologie obscure : "data form", "member selection", "smart view", "cube", "artifact".
Tu veux entrer un budget ? Tu dois d’abord comprendre l’algorithme de propagation dans Essbase.

Un utilisateur Hyperion t'avouera souvent : « Je ne comprends toujours pas comment ça marche, je suis juste le guide qu'on m’a donné… »

🔹 3. Maintenance impossible sans des experts hautement spécialisés

Tu veux modifier une règle de calcul ? Appelle Jean-Claude, le seul gars qui connaît le script en langage HFM.
Tu veux migrer un environnement ? Bonne chance pour le faire sans qu’un module tombe à moitié.

🔹 4. Empilement technique ingérable

Un serveur pour Essbase.
Un autre pour Planning.
Un serveur WebLogic.
Un serveur pour le répertoire partagé.
Un Active Directory.
Un reverse proxy.
Un serveur pour les jobs batch.
…et un café pour survivre à tout ça.

C’est de l’informatique industrielle, pas de l’agilité moderne.

🔹 5. Documentation obsolète dès le mois suivant

Tu termines le guide d'utilisation, puis Oracle change une version, ou ajoute un patch qui casse la moitié de tes scripts de calcul.
Ou pire : la seule doc utile est sur un forum obscur de 2013.

☠️ Et pourtant, on continue...

Pourquoi ? Parce que :

Les données sont critiques.
Les structures financières sont complexes (multi-entité, multi-devises, multi-calendrier).
Et... parce que changer serait encore plus douloureux que de continuer.

💬 En résumé plus honnête :

Oracle Hyperion, ce n’est pas juste un peu de chaos.
C’est une galaxie parallèle de complexité, où seuls les initiés survivent,
et où le chaos est la condition normale de fonctionnement, gérée par des rituels sacrés, des fichiers Excel sacrifiés, et des mots de passe jamais redocumentés.

Si tu veux, on peut s’amuser à écrire un faux manuel de survie pour utilisateur Hyperion, ou un bingo des frustrations courantes. 😄 Ou plus sérieusement, voir comment migrer ou minimiser son usage sans tout casser.

Non, et que penses tu de l'implantation de SAP pour répondre aux besoins de la SAAQ, là ils se sont grandement fo...

Ah, là tu ouvres un vrai chapitre de tragédie numérique québécoise. Oui, la modernisation de la SAAQ avec SAP — projet SAAQclic — a été un échec cuisant, du moins à son lancement, et a mis en lumière tout ce qu’il ne faut pas faire dans un projet technologique à grande échelle.

Tu as raison de dire qu’ils se sont « grandement f… », et ce à plusieurs niveaux : stratégique, technique, organisationnel, et même politique.

🧨 Contexte : Le projet SAAQclic

Objectif : remplacer des systèmes vétustes par une solution moderne centralisée.
Solution retenue : SAP (notamment CRM, ERP, et portail client).
Déploiement : février 2023.
Résultat : effondrement du service à la clientèle, files d’attente monstres, rendez-vous annulés, impossibilité d’accéder à des services en ligne, personnel débordé.

🧱 Pourquoi ça a planté ?

🔹 1. SAP, c’est lourd et rigide

SAP est une solution d’entreprise conçue pour les processus d’affaires standardisés.
Or, la SAAQ avait une réalité métier unique, liée à la réglementation, aux permis, à l’assurance publique.
Résultat : personnalisation excessive de SAP, ce qui va à l’encontre de sa philosophie.

🧨 Tu prends un éléphant conçu pour marcher sur l’autoroute, et tu lui demandes de danser le ballet dans un bureau du gouvernement.

🔹 2. Pas assez de tests / formation

Plusieurs sources internes ont confirmé un manque de tests utilisateurs, ou du moins une validation insuffisante en situation réelle.
Les agents de la SAAQ eux-mêmes ne comprenaient pas bien le système au moment du déploiement.
Résultat : files d’attente, procédures manuelles, débordement du personnel.

🔹 3. Déploiement en "big bang"

Le projet a été lancé en une seule étape massive, au lieu d’un déploiement progressif.
Pas de phase pilote suffisante. Aucune soupape pour revenir en arrière.

C’est comme changer le moteur d’un avion en plein vol — avec des passagers déjà à bord.

🔹 4. Sous-estimation de l’impact client

Le projet était très orienté TI et processus internes, mais a négligé le parcours client, l’ergonomie, l’expérience utilisateur.
L’ancienne plateforme était désuète, mais fonctionnelle.
La nouvelle, bien que plus "moderne", s’est avérée hostile à l’utilisateur, surtout dans les premières semaines.

🔹 5. Mauvaise gouvernance, silos, pression politique

Le projet a impliqué plusieurs partenaires : la SAAQ, le MTQ, des consultants externes, SAP.
Des décisions ont été prises sous pression de délais politiques, et pas toujours avec des considérations techniques en priorité.
Et comme souvent : tout le monde se renvoie la balle après l’échec.

📉 Conséquences

Image publique de la SAAQ gravement ternie.
Audits, commissions, reportages et enquêtes médiatiques.
Des centaines de milliers de Québécois lésés.
Des coûts supplémentaires pour corriger les problèmes post-lancement.
Du personnel en détresse.

🧠 Ce qu’on retient (et ce qu’on devrait retenir)

Leçon	En résumé
Ne jamais sous-estimer l’ergonomie	Surtout dans un service public. L’utilisateur final est roi.
Faire des déploiements graduels	Le Big Bang est rarement une bonne idée dans le public.
Tester en condition réelle	Pas juste en laboratoire ou avec des consultants.
Former les employés en profondeur	Avant, pas après.
Adapter l’outil au besoin, mais jusqu’à un certain point	SAP, Hyperion, etc., ne sont pas des LEGO. Trop de custom = danger.
Ne pas imposer des délais politiques irréalistes	Un système, c’est pas une promesse électorale.

💬 En conclusion

Oui, la SAAQ s’est royalement plantée avec SAP. Pas parce que SAP est une mauvaise solution en soi — mais parce qu’il a été mal adapté à un contexte public complexe, mal implanté, et mal soutenu.

Et comme dans beaucoup de projets publics : le citoyen paie, le fonctionnaire subit, et le fournisseur... facture.

Souhaites-tu une comparaison avec d’autres fiascos technologiques gouvernementaux (comme Phoenix ou SantéConnect) ?

Est-ce seulement au Canada ou au Québec que c'est toujours aussi catastrophique, donne moi d'autres exemples dans le monde pour me consoler.

Tu n’es pas seul, et non, ce n’est pas juste au Québec ou au Canada que les projets informatiques publics tournent au fiasco monumental. Il existe un cimetière mondial de projets numériques gouvernementaux qui ont explosé en vol, englouti des fortunes, semé le chaos administratif… parfois même avec des morts à la clé (au sens propre).

🌍 Tour du monde des projets gouvernementaux qui ont échoué (parfois misérablement)

🇬🇧 NHS – National Health Service IT Modernization (Angleterre)

Coût estimé : £12 milliards (≈ 20 milliards CAD)
But : Informatiser les dossiers médicaux de tous les patients britanniques.
Résultat : Projet abandonné après 10 ans. Incompatibilités, manque de coordination, gaspillage total.
Conséquence : Aucun bénéfice concret. Des systèmes toujours fragmentés.

🧨 Exemple classique d’un projet trop ambitieux, mal piloté, sans écoute des utilisateurs.

🇺🇸 Obamacare – HealthCare.gov (États-Unis, 2013)

Problème : Le site devait permettre à des millions d’Américains de s’inscrire à une assurance maladie.
Ce qui s’est passé :
- Site totalement inutilisable à son lancement.
- Bugs massifs, plantages, inscriptions perdues.
Pourquoi ? :
- Mauvaise architecture.
- Multiplicité des sous-traitants.
- Test incomplet.
Résultat : Réparation d’urgence pilotée directement par la Maison-Blanche.

🔧 Ironie : il a fallu faire appel à… Google et Amazon pour sauver le projet.

🇦🇺 Robodebt (Australie)

Objectif : Système automatisé de recouvrement des dettes auprès des bénéficiaires d’aide sociale.
Résultat : Algorithme erroné → des milliers de personnes ont reçu des lettres les accusant à tort de fraude.
Conséquence :
- Ruines financières.
- Détresse psychologique.
- Des suicides documentés.
Commission royale : condamnation morale et politique sévère.

🤖 Quand tu automatises la répression sans supervision humaine… tu t’exposes à un désastre éthique.

🇫🇷 Louvois – Système de paie de l’armée (France)

But : Simplifier et centraliser le paiement des soldes.
Résultat :
- Des militaires non payés pendant des mois, d’autres trop payés.
- Impossible à corriger.
- Abandonné, remplacé par un autre projet.
Coût estimé : Plus de 500 millions € gaspillés.

🪖 Un soldat qui ne reçoit pas sa paie, c’est un soldat en colère. Ou en grève.

🇩🇪 BER – Aéroport de Berlin-Brandebourg

Bon, ce n’est pas un projet logiciel… mais le parallèle est trop bon.
Retard : 9 ans.
Coût initial : 2 milliards €
Coût final : 7 milliards €+
Problèmes : IT mal conçu, sécurité incendie défaillante, mauvaise gouvernance, erreurs de planification.

✈️ Le « SAP de l’aéroport », en version béton.

🇳🇿 Novopay – Paie des enseignants (Nouvelle-Zélande)

Projet lancé pour moderniser la paie des enseignants du pays.
Résultat : erreurs massives sur les bulletins de paie : enseignants non payés, trop payés, sous-payés.
Les syndicats se sont révoltés.
Le gouvernement a dû reprendre le contrôle du système en urgence.

🧠 Pourquoi ces échecs se répètent-ils partout ?

Facteurs récurrents	Description
❌ Sous-estimation de la complexité	Les décideurs ne comprennent pas la réalité métier ni les contraintes techniques.
❌ Gouvernance éclatée	Trop de partenaires, trop peu de responsabilité claire.
❌ Délais politiques irréalistes	On lance un projet pour une date électorale, pas selon la maturité du système.
❌ Manque de tests utilisateurs	Les systèmes sont pensés pour les gestionnaires, pas pour ceux qui les utilisent.
❌ Mauvais choix technologique	On force un produit inadapté à un contexte unique.
❌ Manque d’humilité technologique	On veut « tout refaire » au lieu d’y aller petit à petit.

✅ Ce qui fonctionne mieux :

Déploiement progressif (par pilote, région, service).
Implication réelle des utilisateurs finaux dans la conception.
Simplicité avant tout.
Responsabilité claire.
Solutions modulaires, ouvertes, flexibles (plutôt qu’un monolithe SAP-like).

🎯 En conclusion

Non, le Québec n’est pas seul à échouer dans ses grands projets numériques. Il fait partie d’une longue tradition mondiale de grands rêves technologiques écrasés par la réalité.

Mais c’est aussi une chance :

Si on apprend de ces erreurs (plutôt que de les camoufler), on peut enfin concevoir des systèmes sobres, utiles, et humains.

Souhaites-tu que je te fasse une courte checklist de ce qu’un projet TI gouvernemental devrait absolument éviter pour ne pas répéter ces échecs ?

On pourrait pas passer une loi pour arrêter d'écouter les gestionnaires! Et juste leur montrer à faire des rapports dans PowerBI pour qu'ils nous crissent patience!

😂 Tu viens probablement de résumer le cri du cœur de toute une génération de professionnels TI, analystes, architectes et développeurs publics. Et tu as raison de le dire avec humour, car derrière la blague, il y a une vérité très profonde et très frustrante.

Alors… jouons un peu le jeu 👇

📜 Projet de loi fictif : « Loi sur la Préservation de la Raison Technologique et l'Émancipation des Systèmes Simples »

Article 1 – Obligation de formation des gestionnaires

Tout gestionnaire de projet TI public devra suivre une formation obligatoire de 20 heures sur Power BI, Excel, Miro, Notion et la limite du mot “intégration”.

Article 2 – Interdiction de dire « C’est juste une petite modification »

Toute personne prononçant cette phrase verra son budget réduit de 15 % et sera redirigée vers un stage de trois mois à faire du support niveau 1 auprès des usagers de la RAMQ.

Article 3 – Droit fondamental à la simplicité

Tout projet comportant les mots « portail », « unifié », « agile SAFe » ou « transformation numérique » devra être revu pour valider s’il n’existe pas déjà trois solutions plus simples dans un coin obscur de l’organisation.

Article 4 – Le comité "On aurait pu juste faire ça dans Power BI"

Instauré dans chaque ministère, ce comité a pour mandat de dire la phrase que tout le monde pense :
« C’est 18 mois de projet pour une table de faits, deux dimensions et un rapport ».

Article 5 – Sanctions pour mégalomanie fonctionnelle

Tout gestionnaire voulant « refondre l’écosystème de services à la clientèle » devra :

Utiliser lui-même le système actuel pendant 3 semaines;
Et écrire son cahier des charges seul, sans l’aide de consultants.

Article 6 – Reconnaissance des architectes et des développeurs

Les personnes qui savent ce qu’est une transaction ACID, un rollback, ou un index sur une colonne JSONB seront écoutées en priorité, car elles vivent dans le réel.

Disposition finale

Cette loi entrera en vigueur dès que l’on aura terminé de « juste ajuster le modèle de données du mois passé qui ne fonctionnait pas mais que tout le monde avait approuvé. »

🤖 Blague à part...

Tu touches un problème réel :

Les gestionnaires ont souvent de bonnes intentions, mais un manque de compréhension technique.
Trop souvent, la TI devient un outil politique, ou un terrain de jeu stratégique.
Et ceux qui comprennent les limites du système… sont consultés trop tard, ou pas du tout.

🎯 Ce qu’on peut faire (vraiment)

Former les gestionnaires à la pensée systémique, à l’agilité réelle (pas SAFe...), et à la sobriété numérique.
Leur faire comprendre que Power BI, SharePoint, Notion ou Excel bien utilisés peuvent régler 80 % de leurs besoins.
Promouvoir des approches bottom-up, où les besoins partent du terrain, pas d’un diagramme PPT en ovale bleu.

Si tu veux, je peux t’écrire une charte du développeur fatigué mais lucide ou une présentation sarcastique à montrer à la prochaine réunion de direction 😄.

La présentation sarcastique oui

🎤 Titre de la présentation :

« Modernisation numérique : Pourquoi faire simple quand on peut faire un PowerPoint de 62 pages »

🎯 Slide 1 – Objectif de la rencontre

Sous-titre : Clarifier notre vision stratégique floue à l’aide d’un diagramme circulaire et d’un acronyme motivant.

✔️ Réaffirmer que le projet est vital.
✔️ Faire semblant qu’on comprend ce qu’est une API.
✔️ Blâmer les développeurs sans le dire trop fort.

💡 Slide 2 – Vision du projet

« Transformer l’expérience citoyenne à l’aide d’une plateforme intégrée, scalable, modulaire, immersive et pro-active. »

✍️ Traduction : On n’a aucune idée précise, mais ça va coûter cher.

🤯 Slide 3 – Pourquoi on n’a pas juste utilisé Power BI

![Image d’un rapport Power BI propre, avec un titre : « Voici ce que vous vouliez. »]

👨‍💼: « Oui mais là c’est pas assez stratégique. »
👩‍💻: « Vous voulez un rapport ou un projet de société ? »

🧱 Slide 4 – Architecture proposée

![Un schéma complexe avec 12 rectangles, 7 flèches et des mots comme "Hub", "Microservice", "Orchestrateur", "BPMN", "SLA", etc.]

Note : Aucun développeur ne comprend vraiment ce diagramme. Mais tout le monde hoche la tête.

🔧 Slide 5 – Ce qu’on aurait pu faire à la place

3 rapports Power BI
1 formulaire SharePoint
1 webhook Zapier
Coût : 2 300 $
Livraison : la semaine passée

📉 Slide 6 – Ce qu’on a fait

11 sprints de cadrage
8 ateliers d’alignement stratégique
5 firmes externes
1 MVP qui ne répond à aucun besoin

👻 Slide 7 – Le MVP

![Image floue d’un écran gris, avec un message d’erreur "Internal Server Error"]

« On est très satisfaits des retours utilisateurs, même s’il n’y en a pas encore eu. »

🧘 Slide 8 – Gouvernance

Comités en place :

Comité directeur
Comité de gouvernance de la gouvernance
Comité d’arbitrage des incertitudes
Sous-comité de pilotage des retards planifiés

🕳️ Slide 9 – Prochaines étapes

✔️ Implémenter la feuille de route de la stratégie d’intégration de la modernisation
✔️ Consolider la migration de l’orchestrateur du CRM dans un silo unifié
✔️ Continuer de faire semblant que tout va bien

🙃 Slide 10 – Ce que le terrain demande vraiment

Que ça marche.
Que ce soit simple.
Que ce ne soit pas un projet pilote éternel.
Que le bouton "Soumettre" ne soit pas gris pâle sur fond gris foncé.

🧠 Slide 11 – Résumé

Ce qu’on a fait	Ce qu’on aurait pu faire
Un gros projet	Une petite solution
Beaucoup de réunions	Une preuve de concept
Une solution imposée	Une demande écoutée
Trop tard	Trop tôt, c’était bien aussi

❤️ Slide 12 – Conclusion

"Les vrais utilisateurs n’ont pas besoin d’un buzzword.
Ils ont juste besoin que le formulaire fonctionne et que le PDF sorte."

Bonus : Slide de remerciement

🎉 Merci pour votre écoute!
🤞 On se revoit au post-mortem du projet dans 18 mois.

mercredi 6 août 2025

Mon amour des progiciels et des projets informatiques...