Discussion :

[ddoumeche]

Pas mieux ! Sauf que les 400 personnes sont venues au fil de l'eau. Et que au fur et à mesure que le logiciel s'enlisait on rajoutait du monde ce qui augmente la complexité et l'enlisement. Tout cela est bien connu comme tu l'indiques.

Là est le piège : l'informatique ne marche pas comme l'industrie automobile, un des meilleurs moyens de ralentir un projet est faire grossir les équipes.

J'ai déjà décrit EPP plus haut mais je complète en schématisant.
EPP = Emploi - Poste - Personne.
Le budget (Bercy) délègue les emplois qui sont réparties dans les académies selon des règles de prorata complexes. Chaque académie transforme à son tour ces emplois en heures (2 degré) ou en poste (1 degré). Sachant que par exemple un certifié doit 18 h, un agrégé 15 heures (résumé simpliste c'est plus compliqué). Dans le 2° degré, Les heures sont agrégées en poste ou fraction de poste (ex: en langue rare un petit ETB n'a besoin que d'un quart de poste). enfin des personnes (enseignants) nommées sur un ou plusieurs postes. Avec des variations dans le temps.
Le tout avec une dotation globale en heures à ne pas dépasser et agrémenté d'heures supplémentaires hebdomadaires, annuelles, de décharges multiples selon le poste, l'enseignant ou la combinaison des deux. par exemple qq heures de décharges pour un syndicaliste. J'oubliais : il faut en plus gérer le remplacement en cas d'absence courte, moyenne ou longue.

C'est du grand classique de la gestion d'entreprise, & j'ai du mal à croire que CapGé n'ai pas déjà cela dans ses cartons. Au pire ils pouvaient acheter une solution sur étagère, avec ses sources ... ce qui est une solution préconisée dans The Mythical Man Month. Quitte à l'adapter et ajouter de la souplesse via un moteur de règles.
Pareillement avec la partie RH.

Dernier point : à l'époque pas de réseau donc des bases par académies avec des stations connectées par câble au serveur UNIX.
EPP est décliné en 3 variantes principales (en arrondi) :
2° degré EPP : 30 bases + 30 autres pour l'enseignement privé.
1° degré AGAPE : 100 bases (une par DPT) + 100 pour le privé.
personnels administratifs AGAPE : 30 bases
Soit 290 bases principales. Mais avec toutes le même schéma et les mêmes applicatifs (à quelques epsilon près ...) truffés cependant de if. Plus de 1 million de lignes répartis principalement en qq milliers de modules. Mais tout est suivi.
Il y a aussi quantité d'applications connexes mais moins importantes pour arriver aux 900 bases.

Et la cible était une ou plusieurs applications et des bases centralisées dans un unique datacenter ? parce que cela nécessite de progressivement remonter ces 900 bases dans cette unique "base".

SIRHEN étant parti d'une feuille blanche avec des concepts "novateurs", en considérant les experts métiers comme subalterne, son modèle est trop différent pour pouvoir récupérer qq chose.

Tu es en train de dire que rien n'est récupérable et que ces 320 millions ont été dépensés en pure perte. Alors que vous pourriez avoir le meilleur logiciel RH du monde... parce que le plus cher

Cela a bien sûr été envisagé. Mais il fallait d'abord reprendre tout le code 4GL en Java et au final on échappait pas au "big-bang" catastrophe. De plus la vieille base Informix supporte mal Hibernate. Pas si simple.

Logique, Hibernate est sorti bien plus tard. Il aurait fallut envisager un upgrade, ce qui est toujours périlleux.

Une solution envisagée, mais non retenue, est de passer à une version moderne du 4GL (Genero de 4js) en passant à une version moderne de la base Informix équivalente à DB2 mais compatible avec nos vieilles requêtes SQL.
L'avantage énorme est que Genero est totalement compatible avec 4GL. En étant aussi performant que Java (et même plus car Genero n'a pas besoin de Hibernate, Spring ...). Le tout en conservant la simplicité du 4GL qui permet à un novice d'être très vite opérationnel. Et pour un prix sans commune mesure avec les sommes dépensées pour SIRHEN.

Les spécialistes Genero sont rares. A partir du moment où vous faites appel à un prestataire, il doit bien utiliser ses compétences internes.

Toute la question est donc de savoir si, pour un grand logiciel de gestion, on doit prendre Java avec toute sa complexité et une architecture qui doit évoluer sans cesse ou bien un langage dédié à la gestion stable et efficace. Sachant que dans le cas présent le code existe déjà : il suffit de le recompiler.

Avec Java, tu as une plateforme ayant encore 30 ans d'espérance de vie minimum et des compétences disponibles sur le marché... alors que tu es + ou - bloqué avec 4GL et risque de te retrouver avec le même souci sur Genero dans 10 ans.
Mais cela uniquement dans l'hypothèse où ton logiciel sort.

[antoine91]

C'est du grand classique de la gestion d'entreprise, & j'ai du mal à croire que CapGé n'ai pas déjà cela dans ses cartons. Au pire ils pouvaient acheter une solution sur étagère, avec ses sources ... ce qui est une solution préconisée dans The Mythical Man Month. Quitte à l'adapter et ajouter de la souplesse via un moteur de règles.
Pareillement avec la partie RH.

Mais CapGemini a bien essayé, également avec un moteur de règles. Seulement ils n'ont pas réussi à obtenir un cahier des charges suffisamment clair et précis.Le moteur de règles n'est pas encore capable d'inventer les règles. Du coup ils se sont concentrés sur la partie RH plus classique. En gros, l'histoire du gars qui cherche ses clés sous un lampadaire par une nuit noire. Et qui ne cherche pas plus loin car seule la zone du lampadaire est éclairée.
Mais simplement sur la partie RH il y a eu des fautes de modélisation qui aurait rendu l'utilisation de SIHREN chaotique même si le logiciel était techniquement parfait (pas le cas bien sûr). Quoique plusieurs audits ont souligné une qualité globalement correcte.
C'est la raison pour laquelle l'EN n'a pas attaqué CapGemini car, pour faire bref, cette entreprise peut prouver qu'elle a fourni un produit de bonne qualité à partir de spécifications foireuses. Produit inutilisable cependant.
A contrario, EPP s'est construit itérativement en symbiose avec la MOA, mais avec un niveau zéro de qualité. Cependant, au final le job est fait et le produit est opérationnel.

Et la cible était une ou plusieurs applications et des bases centralisées dans un unique datacenter ? parce que cela nécessite de progressivement remonter ces 900 bases dans cette unique "base".

Oui.

[antoine91]

Avec Java, tu as une plateforme ayant encore 30 ans d'espérance de vie minimum et des compétences disponibles sur le marché... alors que tu es + ou - bloqué avec 4GL et risque de te retrouver avec le même souci sur Genero dans 10 ans.

Oui.
C'est pour cela justement qu'avec la solution Genero il était envisagé le scénario suivant (pour mémoire le 4GL et la base Informix SE sont en version 1995) :
1) recompilation du code 4GL en Genero
2) upgrade de la base Informix SE en Informix IDS dernière mouture.
3) tester (ces 3 phases ont été expérimentées avec succès)
4) Déploiement progressif partout
5) Urbanisation progressif du métier avec déploiement en continu.
6) Fusion là aussi progressive des bases et urbanisation de la base.
7) Genero permet facilement d'implémenter des webservices. il permet aussi d'inclure du Java (google: 4js genero documentation ...)
Des briques élémentaires (typiquement du code interacitf) peuvent être donc exportées sur un serveur Java qui attaque la base directement ou à partir des données exportées.
8) On termine par l'exportation toujours progressive de Genero vers Java du code métier.
9) C'est fini !
Le processus complet va prendre plusieurs années (5 ans ?), certes. Mais c'est une évolution en douceur avec une amélioration continue de la qualité, de l'ergonomie, ... Pour un coût, en ordre de grandeur, 10 fois inférieur aux sommes dépensées. De plus,en cas de restriction de crédit, on peut suspendre le processus le temps nécessaire en faisant évoluer le produit coté Genero ce qui est plus performant, plus rapide et plus facile à programmer et moins coûteux.

C'est d'ailleurs la crainte (justifiée ?) des tenants de Java largement majoritaires à l'EN : une fois le produit urbanisé en Genero la MOA (ou Bercy) va dire : cela nous suffit.
Il reste cependant l'argument massue cité ci-dessus : quid de Genero à 20 ans - 30 ans ?

[Dendrite]

Bonjour.

Le problème a été en gros celui-ci. Il fallait harmoniser une centaine de bases de données des personnels Education nationale (ATSS, enseignants 2nd degré, enseignants 1er degré , inspecteurs, personnels de direction * une vingtaine d'académies)... Bien sûr, ce sont des réplicats dans chaque académie. La structure des bases est essentiellement la même, les données changent. L'existant a plus de 20 ans et est en informix (IBM). C'est à la fois un SGBD et... un logiciel développé en 4GL, ie en SQL informix, de façon à ce que les gestionnaires administratifs puissent maintenir les bases.

De tout ceci, on voulait construire une base unique nationale en DB2 (ça n'est certainement pas ça le plus difficile)... C'est la partie logicielle pour la maintenance à tous les niveaux qui ambitionnait d'être en SAP qui pose problème... Entre autre car le SAP... n'est plus le maître mot. Dorénavant, on raisonne plutôt en API et micro-services.

Sur le projet national SIRHEN, l'éducation nationale était MOA et avait pris un prestataire. La cour des comptes fin 2016 avait sacrément tiré l'oreille de la direction numérique de l'éducation nationale, car ce n'était absolument pas le prestataire, la maîtrise d'oeuvre qui était en cause, mais le manque de cohérence, compétence, professionnalisme... de la maîtrise d'ouvrage côté EN. De ce que j'ai compris, des multitudes de MOA intermédiaires ne parvenaient pas à accorder leurs violons... ce qui faisait tourner le projet infiniment en rond. Donc Cinephil, le problème n'est pas le développement, mais le pilotage de ce projet.

Blanquer a arrêté les frais. Soit. Je ne suis pas compétente pour juger du bien fondé de cette décision bien évidemment.
Mais bien des questions subsistent :
- Au départ, ce projet s'inscrivait surtout dans un projet plus général d'unification de la paie de TOUS les fonctionnaires. Ce projet étant tombé à l'eau... SIRHEN perdait beaucoup de son utilité.
- Moderniser la gestion administrative des salariés de l'EN reste une question à part entière. Et surtout côté applicatif.
- Les inspecteurs et chefs d'établissement vont-ils rester dans IRHEN (la base DB2) comme des vestiges ou bien vont-ils réintégrer EPP en attendant à nouveau une solution globale.
- Sur le fond, il y aura toujours des divergences d'intérêts entre des académies aux directions locales et le ministère. Qui administre ? Qui maintient ? Quelles applis peuvent être standard ou non ?

Pour conclure, dans ce sondage, il manque la ligne suivante : défaillance du pilotage national...

edit : oh my god, Antoine, je viens de lire tous tes messages ! Je kiffe grave ! Reviens, on a besoin de toi à l'éducation nationale !

[Marco46]

le manque de cohérence, compétence, professionnalisme... de la maîtrise d'ouvrage côté EN. De ce que j'ai compris, des multitudes de MOA intermédiaires ne parvenaient pas à accorder leurs violons... ce qui faisait tourner le projet infiniment en rond. Donc Cinephil, le problème n'est pas le développement, mais le pilotage de ce projet.

Effectivement, connaitre le métier et être capable de rédiger une spécification à destination à minima de concepteurs techniques et au mieux de développeurs c'est un métier en soit. Ça ne s'improvise pas. Probable que un problème initial est d'avoir pensé qu'il était possible de se servir du personnel fonctionnel de l'EN pour rédiger les EDB et les specs sans assistance.

Reste en bout de ligne le problème de l'arbitrage final pour faire avancer les décisions, les clients ont souvent du mal à confier du pouvoir décisionnel à des prestataires.

[antoine91]

Sur le projet national SIRHEN, l'éducation nationale était MOA et avait pris un prestataire. La cour des comptes fin 2016 avait sacrément tiré l'oreille de la direction numérique de l'éducation nationale, car ce n'était absolument pas le prestataire, la maîtrise d'oeuvre qui était en cause, mais le manque de cohérence, compétence, professionnalisme... de la maîtrise d'ouvrage côté EN. De ce que j'ai compris, des multitudes de MOA intermédiaires ne parvenaient pas à accorder leurs violons... ce qui faisait tourner le projet infiniment en rond. Donc Cinephil, le problème n'est pas le développement, mais le pilotage de ce projet.

Bonjour et merci car je commençais à me sentir un peu seul à connaître les entrailles de la bête
Rectification : l'existant (EPP voir plus haut) date de 1989 soit 30 ans.
Le problème est plus profond. Au fil des années les MOA, surtout celles qui ont été consultées , ont perdu le savoir au profit de l'application : toute la connaissance a migré progressivement dans le code, de manière complexe. Les développeurs, au fil du temps (20-30 ans c'est long !) sont partis ou ont oublié. De plus, malgré des alertes fin des années 1990 (!) le code n'a jamais été urbanisé. La réponse était : attendez SIRHEN qui va tout résoudre avec des méthodes modernes (en méprisant implicitement les anciens ?).
Cependant, l'étude du vieil EPP comme cahier des charges reste encore possible avec les quelques dinosaures restants de cette époque. Toutefois ces derniers sont très proche de la retraite et passablement écœurés. Mais avec l'aide précieuse des vrais utilisateurs (les gestionnaires et ADSI) qui connaissent bien l'existant à travers l'applicatif tout reste encore possible. Leur aide sera déterminante car dans tout l'empilage depuis 30 ans c'est eux qui peuvent faire la part du bon grain et de l'ivraie.
Mais tu as raison CapGemini n'est pas responsable de cela. Ils ont subi.

Toutefois ils ont failli gravement par manque d'obligation de conseil : ils auraient dû rendre leur tablier dés 2009-2010. Mais la soupe était bonne, les millions tombaient. Pour quelques rares lanceurs d'alerte qui osait l'ouvrir (dont certains durement sanctionnés) tout était en place pour le désastre annoncé. Et tout s'est passé comme prévu mais beaucoup plus tard.
CapGemini aurait dû arrêter les frais en 2010 et le Ministère vers 2012-2014. Mais il en faut du courage pour stopper un tel monstre ! Surtout que, au fil du temps, la bête grossit et lamine tout sur son passage. Il faut au moins être Ministre, sinon ...

[fredoche]

Pour ma gouverne quel est l'intérêt de centraliser au plan national ? Et de ne pas rester à un niveau académique ?

Je trouve cette discussion très intéressante et c'est mignon de dédouaner CGEY, mais j'ai du mal à m'enlever de l'esprit que reposer sur de la prestation de service, c'est tout simplement nier quelques facteurs humains qui concourent à la réussite ou l'échec d'un projet ou d'un autre.

Louvois puisqu'on y fait référence en filigrane pour l'échec du projet portant ce nom, est connu pour avoir fidélisé et organisé les armées de Louis XIV, instituant la solde régulière des soldats, et s'opposant à la vénalité de la charge des officiers. La solde était remise en mains propres aux soldats.

la vénalité de ces officiers qui étaient les intermédiaires entre les caisses du roi et ses soldats, et qui se servaient partout où ils pouvaient.

La fidélité à une entreprise, à un projet, les notions de bien commun, de destin commun, de responsabilité commune.

Les salariés de CGEY, c'est pas l'état ni l'EN leur employeur.

On compare souvent le salarié de SSII à un mercenaire non ? Qui rend des comptes à qui en fin de compte

[antoine91]

Pour ma gouverne quel est l'intérêt de centraliser au plan national ? Et de ne pas rester à un niveau académique ?
Je trouve cette discussion très intéressante et c'est mignon de dédouaner CGEY, mais j'ai du mal à m'enlever de l'esprit que reposer sur de la prestation de service, c'est tout simplement nier quelques facteurs humains qui concourent à la réussite ou l'échec d'un projet ou d'un autre.

Si tu lis la discussion depuis le début tu verras qu'il a été dit, et pas que par moi, qu'un tel logiciel ne peut pas être réalisé par des prestataires ! Justement parce que un prestataire attend des cahiers des charges quasi-parfaits, impossibles à faire. Du coup ils bâtissent sur des sables mouvants. Et, par ailleurs je critique CapGemini pour ne pas avoir alerter dés 2009-2010 qu'ils étaient à la rue.
Je me répète : L'ancien logiciel, EPP toujours actif heureusement, 30 ans d'age, a été conçu presque entièrement en interne avec des fonctionnaires certes moins bon que les experts de CapGemini mais connaissant le métier. Du coup, ce fut (c'est) une réussite et SIRHEN un échec. Et il continue d'absorber l'évolution permanente.

Pourquoi centraliser ?
1) dans le système actuel réparti quand un agent change d'académie c'est la galère : extraire toutes les données, les transporter, puis intégrer de l'autre coté. On pourrait certes améliorer.
2) Chaque académie à tendance à personnaliser sa base avec un risque de divergence.
3) Quand on veut faire des enquêtes transverses c'est aussi la galère.
4) il faut une multitude d'équipes systémes - réseaux - DBA et de serveurs.
5) Avec une base centralisée on peut plus facilement redonder les bases, les équipes, les serveurs le tout à moindre coûts.
non exhaustif ...

[Marco46]

Et, par ailleurs je critique CapGemini pour ne pas avoir alerter dés 2009-2010 qu'ils étaient à la rue.

Ils l'ont peut être fait et n'ont pas été écoutés.

J'ai déjà vu le cas de figure, le client veut refondre un existant mais veut (pense) faire porter le risque sur ses prestas. Donc il demande de la MOE au forfait avec des pénalités. Si le presta livre en retard ou avec des bugs bloquants alors il sera contraint contractuellement de les régler. Donc c'est le presta qui porte le risque C'est du moins le raisonnement de ces managers surdoués. Sauf que au forfait tes specs ça doit être du béton armé parce que ça devient ton contrat avec ton presta, et c'est là que ça commence à merder.

Là dessus le prestataire alerte sur le risque : Cher client le risque n'est pas là où vous le pensez. On sait d'expérience que le forfait pour faire de la réalisation de projet de refonte d'existant avec des règles qui bougent c'est très compliqué. On préférerait mettre du monde en régie chez vous à côté des sachants et fonctionner en agile.

Comme c'est une stratégie globale d'entreprise que de sous-traiter sa MOE et d'outsourcer tout ce qui peut l'être (surtout à Paris, réduction massive des loyers et autres frais adjacents) la réponse est connue : Non.

Mais le presta a bien levé son alerte, simplement le client n'en a rien à cirer.

Peut-on reprocher à la SS2I de ne pas encaisser les chèques alors qu'elle a prévenu dans les grandes largeurs ? Si elle descend de la barque un de ses concurrents montera à sa place.

Le problème initial c'est le client, à force de sous-traiter on perd toute forme de compétence et on gaspille des centaines de millions s'en même comprendre comment.

Pourquoi centraliser ?
[...]

Ne vous inquiétez pas, Mounir Mahjoubi a dévoilé la stratégie cloud du gouvernement.

Il a dit que en 2022 ça sera livré. Il l'a dit donc c'est bon ça roule. En 2023 ils refondent l'appli, en 2024 c'est dans le claouwde. En 2025 ils trouvent un vaccin contre le sida, en 2026 une cure contre le cancer, en 2027 Macron règle le conflit israélo-palestinien, et en 2028 ils prendront 10 jours de vacances.

Bref, @ddoumeche citait "The Mythical Man-Month: Essays on Software Engineering" de Fred Brooks, dans les lectures intéressantes du même auteur il y a aussi "No Silver Bullet: Essence and Accidents of Software Engineering", pas certains que ces gens la aient pris le temps d'avoir une culture informatique suffisamment étoffée pour comprendre ces problématiques. Et si oui, probable que ça passe très loin derrière les impératifs de communication et de carrière.

[fredoche]

Si tu lis la discussion depuis le début tu verras qu'il a été dit, et pas que par moi, qu'un tel logiciel ne peut pas être réalisé par des prestataires ! Justement parce que un prestataire attend des cahiers des charges quasi-parfaits, impossibles à faire. Du coup ils bâtissent sur des sables mouvants. Et, par ailleurs je critique CapGemini pour ne pas avoir alerter dés 2009-2010 qu'ils étaient à la rue.
Je me répète : L'ancien logiciel, EPP toujours actif heureusement, 30 ans d'age, a été conçu presque entièrement en interne avec des fonctionnaires certes moins bon que les experts de CapGemini mais connaissant le métier. Du coup, ce fut (c'est) une réussite et SIRHEN un échec. Et il continue d'absorber l'évolution permanente.

Pourquoi centraliser ?
1) dans le système actuel réparti quand un agent change d'académie c'est la galère : extraire toutes les données, les transporter, puis intégrer de l'autre coté. On pourrait certes améliorer.
2) Chaque académie à tendance à personnaliser sa base avec un risque de divergence.
3) Quand on veut faire des enquêtes transverses c'est aussi la galère.
4) il faut une multitude d'équipes systémes - réseaux - DBA et de serveurs.
5) Avec une base centralisée on peut plus facilement redonder les bases, les équipes, les serveurs le tout à moindre coûts.
non exhaustif ...

Oui en réalité j'avais bien compris ton point de vue, je lis depuis le début
Il n'y a aucune certitude sur le fait que des fonctionnaires soient moins bons que les "experts" CG. Si l'on en juge à l'aune des résultats tout du moins.

je vois bien le point 5 comme étant le plus admis(-sible) et probablement le plus valide, mais on parle aussi de notre époque, donc les réseaux existent effectivement, RENATER c'est pas l'EN par hasard ? Et les équipes peuvent être redondées, et travailler à distance, sans centraliser les infrastructures, et surtout les bases pour autant.
Les architectures modernes, c'est aussi décentraliser, démultiplier les services, etc... Les gros monolithes, je ne sais pas si c'est encore trop d'actualité.

je posais la question parce que le fonctionnement EN reste académique lui, et que quelque part cette centralisation nationale me parait aussi pouvoir introduire d'autres écueils, dans l'idée d'un portage d'un système existant et fonctionnant bien (ou tant bien que mal) mais au niveau académique comme tu le soulignes.

Les autres points peuvent être résolus il me semble avec les réseaux modernes.

[antoine91]

En poussant le bouchon dans le même sens mais un peu plus loin on peut avoir une architecture centralisée et répartie.

Il y a une seule base logique à un seul endroit physique mais répartie selon les 30 académies avec 30 serveurs (ou silos).
Chaque table "métier" de la base est répartie selon l'académie sur chacun des 30 silos.
les droits sont stricts : une académie ne peut écrire que dans son silo mais éventuellement lire une partie d'un autre silo : si un enseignant change de silo l'ancienne académie a besoin pendant un certain temps de lire ses données pour faire des opérations rétroactives.
Au final, tout se passe comme si chaque académie avait sa propre base dans sa propre salle machine grâce aux réseaux performants. Si un silo tombe les autres continuent, tout comme maintenant. Si un silo est en surcharge, les autres sont indifférents.
Pour changer un enseignant de silo un simple update (niveau DBA) de l'identifiant des tables maîtres suffit. Les droits passent de écriture à lecture et réciproquement via un trigger. Dans la même transaction les données sont physiquement déplacées.
Le pilotage national ou DBA est le seul à avoir des droits transverses en lecture seule bien sur. Et qui peuvent être momentanément invalidés si une académie lance un batch avec beaucoup d'écritures.
Tout ceci piloté par des ihm gérant les droits selon les profils.

On cumule ainsi tous les avantages sans les inconvénients. Un lecteur expert des BDD sur ce forum pourrait bien mieux que moi préciser tout cela.
C'est un expert d'IBM de haut niveau qui m'avait indiqué cela il y a une douzaine d'années. Cela permet en plus, pour les requêtes transverses DBA, de les paralléliser.
J'espère avoir bien retenu la leçon.

Mais cette architecture n'a pas été retenue pour SIRHEN, au profit d'un silo virtuel par agent qui pose des problèmes catastrophiques quand on veut gérer par exemple la consommation des moyens de tous les enseignants d'un ETB voire de l'académie.

Evidement on peut subdiviser plus finement : 1° degré (écoles) et 2° degré (collèges et lycées), privé versus public, personnels administratifs, département au lieu d'académie ... Pour retomber exactement sur les 300 bases principales actuelles (détail plus haut). Ce qui a du sens au niveau gestion.

[Marco46]

via un trigger

Attention, un trigger ou une procédure stockée ça veut souvent dire mettre du métier dans le SGBD, et c'est mal !

une académie lance un batch

Un batch qui appelle le composant core contenant tout le métier alors ? Composant core qui doit être écrit dans un langage très largement utilisé, opensource et pour lequel il est facile de trouver des ressources ?

[François DORIN]

Attention, un trigger ou une procédure stockée ça veut souvent dire mettre du métier dans le SGBD, et c'est mal !

Rien de mal à cela. Cela a même de nombreux avantages. Et les avantages compensent largement les inconvénients pour moi.

De plus, si on en le fait pas, alors le SGBD est juste un moteur de stockage. Alors que c'est bien plus puissant que ça ! Il serait vraiment dommage de ne pas profiter de toute la puissance du SGBD.

[antoine91]

Attention, un trigger ou une procédure stockée ça veut souvent dire mettre du métier dans le SGBD, et c'est mal !

Justement, il me semble que SQLpro qui a détaillé le calcul du coût en années en page 2 avait il y a longtemps (10 ans, plus ?) écrit un article dans lequel il expliquait que le "métier profond" était mieux à sa place dans des procédures stockées, au plus près de la base, plutôt qu'au milieu d'une architecture n-tiers.
Je comprends aussi ton point de vue. Où en est le consensus, ou son absence, sur ce point délicat ?

Un batch qui appelle le composant core contenant tout le métier alors ? Composant core qui doit être écrit dans un langage très largement utilisé, opensource et pour lequel il est facile de trouver des ressources ?

Simplement un batch qui va mettre à jour beaucoup de données, ou une campagne avec des données provisoirement instables. Le responsable académique ne veut pas que l'on lise sa base durant cette période d'instabilité et en déduire des indicateurs incorrects. C'est la méthode "metier' actuelle. Le ministère demande de passer un programme de récolte d'informations pour faire une synthèse nationale. Mais le responsable académique attend une fenêtre propice quand il estime que ses données sont bien stables.

[micka132]

Attention, un trigger ou une procédure stockée ça veut souvent dire mettre du métier dans le SGBD, et c'est mal !

C'est mal, ou pas!
Cycle en V, Agile, ou à la rache?
Cloud ou dans la chambre?
Je pense pas qu'il y ai jamais eu de meilleurs réponses, mais uniquement des idées dominantes avec les prises de décision qui s'en suivent.
Pour autant les projets continuent à avoir un taux de réussite assez stable à travers les décennies. Je ne pense donc pas qu'il y ai un rapport entre les technos, l'archi ou les méthodes et le succès d'un projet. C'est le facteur humain le problème, et au plus le projet est gros au plus c'est problématique.

[ddoumeche]

Mais CapGemini a bien essayé, également avec un moteur de règles. Seulement ils n'ont pas réussi à obtenir un cahier des charges suffisamment clair et précis.Le moteur de règles n'est pas encore capable d'inventer les règles. Du coup ils se sont concentrés sur la partie RH plus classique. En gros, l'histoire du gars qui cherche ses clés sous un lampadaire par une nuit noire. Et qui ne cherche pas plus loin car seule la zone du lampadaire est éclairée.
Mais simplement sur la partie RH il y a eu des fautes de modélisation qui aurait rendu l'utilisation de SIHREN chaotique même si le logiciel était techniquement parfait (pas le cas bien sûr).

J'ai quand même du mal à croire que CapGéGé soit incapable d'intégrer les différents cas d'utilisation d'une seule catégorie de personnel dans un moteur de règles. Celle qui aurait été utilisée pour commencer. D'autant qu'il n'y a sans doute des milliers de cas au final, mais que l'on travaille un nombre limité d'objets. L'idée derrière le moteur de règles est que ce soit le client qui écrive les règles
Tu sais, la fable chinoise sur apprendre a un homme à pêcher....

A vouloir rester dans le cadre strict des spécifications sans faire de l'itératif, voila comment finissent les projets.

Si le logiciel est inutilisable, il est déficient, peu importe la qualité du code derrière.
Dans le privé, quand quelqu'un a le malheur de merder, le directeur le convoque. Et si cela ne suffit pas, le client nous convoque et on s'explique entre huit yeux, histoire de voir où en est le projet. Et s'il ne serait pas mieux géré avec une personne à temps plein à Gdansk. Temporairement.

Oui.
C'est pour cela justement qu'avec la solution Genero il était envisagé le scénario suivant (pour mémoire le 4GL et la base Informix SE sont en version 1995) :
1) recompilation du code 4GL en Genero
2) upgrade de la base Informix SE en Informix IDS dernière mouture.
3) tester (ces 3 phases ont été expérimentées avec succès)
4) Déploiement progressif partout
5) Urbanisation progressif du métier avec déploiement en continu.
6) Fusion là aussi progressive des bases et urbanisation de la base.
7) Genero permet facilement d'implémenter des webservices. il permet aussi d'inclure du Java (google: 4js genero documentation ...)
Des briques élémentaires (typiquement du code interacitf) peuvent être donc exportées sur un serveur Java qui attaque la base directement ou à partir des données exportées.
8) On termine par l'exportation toujours progressive de Genero vers Java du code métier.
9) C'est fini !
?

Projet itératif d'urbanisation sur 5 ou 10 ans, j’approuve, même si cela ne semble pas répondre à la problèmatique du partage des données entre académies et entre sites.
Il manque juste le plus important, la rédaction des spécifications qui devrait se trouver en haut de la liste et en parallèle (confié à la MOA et à la technique).

C'est quoi la suite, la fonction publique sort un nouvel Opérateur National de Paye, en espérant qu'ils y arrivent cette fois-ci ?

Bonjour.

De tout ceci, on voulait construire une base unique nationale en DB2 (ça n'est certainement pas ça le plus difficile)... C'est la partie logicielle pour la maintenance à tous les niveaux qui ambitionnait d'être en SAP qui pose problème... Entre autre car le SAP... n'est plus le maître mot. Dorénavant, on raisonne plutôt en API et micro-services.

Remonter les données en un point unique est trivial, c'est la redescente des données modifiées vers les bases locales qui est un peu plus complexe.
Et encore faut-il savoir ce qu'on entend par API monolithique et micro-services, et si tant est que les micro-services fassent un jour preuve de leur supériorité, ce qui est loin d'être acquis.

N'as tu jamais eu de projet avec des dizaines de MOA se tirant dans les pattes ?
Dans ce genre de cas, c'est à la maîtrise d'œuvre d'imposer les choix, plutôt que de laisser le projet partir en vrille. La cour des comptes a aussi pointé les défaillances de la MOE.

MOE qui peut toujours prendre la décision de bloquer le projet a titre conservatoire, voir dans le pire des cas, menacer de partir. Le client peut toujours imaginer de reprendre un autre prestataire, tout en sachant que dans 75% des cas, cela signifie la mort du projet.

Pourtant la solution est bien connue de tous les vrais professionnels : prendre la méthode Agile, installer le plugin IMB.Migrate® 7.2 sur Eclipse 5.1.8.451297mk2 (sur Windows Vista donc), importer le projet 4GL dans Eclipse et le convertir en maven, cliquer sur la pomme, choisir Run as > Maven migrate dans le clown.
Et tu n'as plus qu'à choisir ton prestataire de clown.

Je relirais "No Silver Bullet: Essence and Accidents of Software Engineering". Pour rire un peu (pour les anglophones), le récit d'un projet informatique à Paris:
https://projectfailures.wordpress.co...from-hell/amp/

[Dendrite]

Rien de mal à cela. Cela a même de nombreux avantages. Et les avantages compensent largement les inconvénients pour moi.

De plus, si on en le fait pas, alors le SGBD est juste un moteur de stockage. Alors que c'est bien plus puissant que ça ! Il serait vraiment dommage de ne pas profiter de toute la puissance du SGBD.

Same here !
Tu ouvres la base, et tu comprends les règles de gestion dès que tu maîtrises bien la modélisation et SQL... En regardant les vues, les triggers, les tables matérialisées...
Je SAIS que ce n'est pas la mode, mais c'est juste super pratique pour l'informatique de gestion, de faire porter tous les calculs au SGBD.
Sinon quoi ? Tout est dans la doc, dans les commentaires heu... si tu as eu le temps de les mettre à jour...
J'aime moi que dans mes applis locales, une meta-table porte les règles de gestion, et le SQL qui va bien avec. Une bonne requête vaut largement 3 pages d'explication en matière de doc technique.

Justement, il me semble que SQLpro qui a détaillé le calcul du coût en années en page 2 avait il y a longtemps (10 ans, plus ?) écrit un article dans lequel il expliquait que le "métier profond" était mieux à sa place dans des procédures stockées, au plus près de la base, plutôt qu'au milieu d'une architecture n-tiers.

Normal, c'est mon gourou.
Si t'as le lien...

edit pour info :

En matière d'académie, l'EN s'aligne aussi sur les nouvelles grandes régions (13 en métropole). Et des recteurs d'académie ont la double casquette de recteur de région : exemple, le Recteur de la région académique Île-de-France est aussi le recteur de Paris, et il y a le recteur de Créteil et le recteur de Versailles ... Donc ça se centralise. J'aime bien tes explications Antoine sur la souplesse possible entre les accès en écriture/lecture et les accès en lecture seule selon les silos.

[Marco46]

Je ne pense donc pas qu'il y ai un rapport entre les technos, l'archi ou les méthodes et le succès d'un projet. C'est le facteur humain le problème, et au plus le projet est gros au plus c'est problématique.

Oui, c'est en tout cas le point de vue de Fred Brooks :

I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation.

[...]

If this is true, building software will always be hard. There is inherently no silver bullet.

Je pense pas qu'il y ai jamais eu de meilleurs réponses, mais uniquement des idées dominantes avec les prises de décision qui s'en suivent.

Oui, mais je parlais du point de vue de la Clean Architecture. Dans ce cas de figure on veut séparer le métier des solutions techniques. Placer du métier dans un SGBDR c'est aller à l'encontre de ce principe. Aujourd'hui on a une BDD relationnelle, demain on pourrait vouloir transférer tout ça dans une solution big data par exemple. Dans ce contexte, comme le dit François DORIN : "alors le SGBD est juste un moteur de stockage".

Justement, il me semble que SQLpro qui a détaillé le calcul du coût en années en page 2 avait il y a longtemps (10 ans, plus ?) écrit un article dans lequel il expliquait que le "métier profond" était mieux à sa place dans des procédures stockées, au plus près de la base, plutôt qu'au milieu d'une architecture n-tiers.

Venant de lui ce n'est pas tellement étonnant c'est son domaine d'expertise ! Et ce n'est pas du tout le point de vue de Robert C. Martin, il a un point de vue totalement opposé même.

Je comprends aussi ton point de vue. Où en est le consensus, ou son absence, sur ce point délicat ?

Il n'y a pas de consensus, il n'a ni tord ni raison, comme Robert C. Martin n'a ni tord ni raison.

C'est toujours pareil, avantages et inconvénients, et ça dépend du contexte.

L'inconvénient de la solution de SQLPro c'est qu'elle crée une adhérence très forte avec un produit. Et c'est difficile de croire que le serveur d'application ne contienne pas de métier, on va donc avoir des règles dupliquées entre la couche applicative et la couche persistance et donc les problèmes qui vont avec. Et je parle même pas de la testabilité. Difficile de faire de l'agile de cette manière.

D'une manière générale : there is no silver bullet

[Marco46]

Sinon quoi ? Tout est dans la doc, dans les commentaires heu... si tu as eu le temps de les mettre à jour...
J'aime moi que dans mes applis locales, une meta-table porte les règles de gestion, et le SQL qui va bien avec. Une bonne requête vaut largement 3 pages d'explication en matière de doc technique.

Sinon tu as le TDD :

https://vimeo.com/68375232 (j'arrive pas à linker ça proprement :/)

Ce qui revient à avoir des specs exécutables au lieu de milliers de pages de word / ppt.

[antoine91]

Projet itératif d'urbanisation sur 5 ou 10 ans, j’approuve, même si cela ne semble pas répondre à la problèmatique du partage des données entre académies et entre sites.Il manque juste le plus important, la rédaction des spécifications qui devrait se trouver en haut de la liste et en parallèle (confié à la MOA et à la technique).

Dans la liste en 9 points que j'indique il y a fusion des bases. Et donc toutes données sont stockées au même endroit et partageables par tous les acteurs selon leurs droits. De plus dans
mon post de 17h 37 j'indique comment on peut avoir une base à la fois répartie (partagée donc) et centralisée.

La rédaction des spécifications est implicite dans la section "Urbanisation progressif du métier". En pratique c'est donc le vieux code EPP qui contient les spécifications. Il "suffit" de mettre au propre ce vieux code, module après module et d'en déduire ces spécifications.

L'inconvénient de la solution de SQLPro c'est qu'elle crée une adhérence très forte avec un produit. Et c'est difficile de croire que le serveur d'application ne contienne pas de métier,

Je ne retrouve pas son article. En voici un sur les clés étrangères qui reprend les mêmes thèmes : https://sqlpro.developpez.com/article/fk-sql-vs-appli/
Par exemple : Je pense qu'indiquer les clés primaires et étrangères dans la base fait consensus. Une facture doit être attachée à un client.
Autre exemple : on peut indiquer dans la base que le surbooking est interdit. Quel que soit l'applicatif (et ils peuvent être divers et variés surtout à l'EN) il sera contraint. Sinon, il faut penser à implémenter la contrainte dans tous les codes applicatifs. Et il y aura toujours un nouveau programme dans un nouveau langage qui ne fera pas le contrôle. Ce code et cette base sont parties pour durer 30 ans et plus et on changera peut être de langage mais pas de base. Actuellement, dans EPP, on utilise au moins 3 langages différents : 4GL, Java, scripts SQL. Et sans contrainte d'intégrité. Du coup, la base est de qualité disons inégale .
Ou encore (déconseillé !) une mise à jour directe en DBA dans la base. Tu me diras le DBA peut faire sauter les contraintes à la hache ...

C'est pour cela que j'ai bien indiqué "code métier profond". Pas tout le code métier donc mais le plus essentiel. Tout le reste est dans le code applicatif. La difficulté est où placé le curseur. Comme tu dis il n'y a pas de solution magique.
J'espère que j'ai correctement reproduit la pensée de SQLpro.