Discussion :

[antoine91]

Ils auraient simplement du acheter des logiciels du marché qui font déjà le boulot et sont utilisés par des organisations tout aussi compliqué que sont les grandes entreprises

Cela a été longuement étudié mais vu la complexité et l'énorme volume de code spécifique nécessaire SAP et consorts ont jeté l'éponge lors des études préalables.

[antoine91]

On est quand même très loin d'un simple logiciel de paie !

Effectivement la paye représente 10-20%.

Le cout de l'appli, chiffré initialement à 60 millions d'euros, est manifestement très très insuffisant. C'est le problème de vouloir faire des trucs énormes d'un coup sur plusieurs années au lieu d'itérer rapidement sur des petits scopes.

L'ancienne appli (qui gère tout ce qui est indiqué plutôt bien mais avec une ergonomie passée de mode) a coûté de cet ordre de grandeur : 15-20 personnes de 1989 à 2017. Mais il est vrai qu'elle a été réalisée très progressivement en termes de populations et de fonctionnalité croissantes. Une simple rénovation-modernisation (toujours possible d'ailleurs) aurait coûté 2 à 3 fois moins. Mais il y a eu un peu (beaucoup ?) de folie des grandeurs.

Mais bref ... Je suis curieux de savoir qu'elles sont les SS2I qui se sont goinfrées sur ce marché public, parce que je ne doute pas une seule seconde que ce projet a été réalisé intégralement par des prestataires.

C'est dans la presse : CapGemini principalement et Steria avec un petit tiers de fonctionnaires "subalternes".
A noter que l'ancienne application a été réalisée avec 90% de fonctionnaires connaissant bien le métier et qui, à l'inverse, dirigeaient les prestataires.

[François DORIN]

Le calcul est faux d'un facteur 10 ! :
20j * 500 Euros * 12 mois * 20 personnes * 11 ans = 26 400 000 = 26.4 millions d'euros.
En réalité c'est de l'ordre de 200 personnes sur 10 ans. Ce qui avec qq frais annexes arrivent à la somme indiquée.

Oh my god... j'ai effectivement oublié un zéro Merci pour la rectification. J'édite mon message initial pour pointer cette erreur.

[ddoumeche]

Cela a été longuement étudié mais vu la complexité et l'énorme volume de code spécifique nécessaire SAP et consorts ont jeté l'éponge lors des études préalables.

Etonnant, SAP gère 150 millions d'utilisateurs dans son cloud. N'auraient-ils pas plutôt été échaudés par une quelconque (dés)organisation des ministères ?

[antoine91]

Le pire dans tout cela ? Le montant ne correspond que très peu à du développement/conception d'application. Exemple, à partir des chiffres donnés : 320 millions d'€, si ce n'était que du développement, cela représenterait 1750 années de développement pour un seul homme (sur une base de 500€/j et travaillant 365/an)

À titre d'exemple, je viens de faire le calcul. Basé sur une équipe de 20 personnes (une belle équipe), travaillant non-stop pendant 11 ans (20/j par mois) et toujours à 500€/j, cela fait un coup de 2.6426.4* millions d'euros.

On peut rajouter quelques frais annexes (hébergement, matériel, etc...). On monte à 3 millions d'euros pour la conception et le développement.
---
* on m'a très justement fait remarqué une erreur d'un facteur 10 dans mon calcul. Le calcul de base correspond donc à 10% de la somme total au lieu des 1% comme initialement calculé... Quoiqu'il en soit, cela ne change pas le fait que la plus grande partie des coûts n'est pas liée au développement...

Je suis désolé d'insister mais votre hypothèse de 20 personnes est également entachée d'une erreur d'un facteur 10. Il y avait même 400 personnes sur le projet ces derniers temps. Disons donc 200 en moyenne sur 10 ans. Il faudrait aussi rectifier le 3 millions en 30. On arrive ainsi à 100%.
Pour l'essentiel ce sont des prestataires de Cap Gemini. C'est un projet vraiment gigantesque : plus de 1 million de personnes à gérer avec un très grand nombre de cas d'utilisation . La fonction publique est très complexe.

Cependant je suis d'accord sur le fond de votre primo-analyse : un tel projet n'aurait dû mobiliser que 20 personnes (vous aviez vu juste) et non 200. D'ailleurs l'ancien logiciel (son petit nom : EPP) à implémenter l'ensemble des fonctionnalités décrites avec une moyenne de 20 personnes en une vingtaine d'années (1989 à 2007 donc). Soit 400 années-hommes. Depuis il est en mode maintenance-évolution à minima en continuant à accumuler une dette technique colossale. Mais il fait le job.
Le nouveau est à 200 * 10 soit 2 000 années-hommes pour ne pas faire le travail (à part 2% de la population).
De plus l'ancien a été développé dans une technologie antique : informix 4GL resté en version 1995 et 10% de C avec vi, make, grep et sed comme atelier de développement. Le tout sur des serveurs RedHat. Les développeurs étaient en majorité des fonctionnaires avec un maigre bagage informatique mais une excellente connaissance métier.

Alors que le nouveau a utilisé Java avec toute la galaxie classique : Hibernate, Spring, JSF, ... et bien sûr Eclipse. Et avec des développeurs bien plus costauds. CapGemini a fourni des pointures.

La question est donc : pourquoi 400 années-homes de "fonctionnaires branquignols" a réussi alors que 2 000 années-hommes de "cadors du privé" a échoué (le tout en ordre de grandeur bien sûr) ? Surtout qu'ils pouvaient prendre l'ancien comme cahier des charges. Mais ils sont partis d'une feuille blanche. En annonçant que, avec de vrais informaticiens, on allait enfin passer à quelque choses de sérieux. Le tout avec peut être (?) une pointe de mépris.

J'ai quelques éléments de réponse si cela intéresse.

[François DORIN]

Je suis désolé d'insister mais votre hypothèse de 20 personnes est également entachée d'une erreur d'un facteur 10. Il y avait même 400 personnes sur le projet ces derniers temps. Disons donc 200 en moyenne sur 10 ans. Il faudrait aussi rectifier le 3 millions en 30. On arrive ainsi à 100%.
Pour l'essentiel ce sont des prestataires de Cap Gemini. C'est un projet vraiment gigantesque : plus de 1 million de personnes à gérer avec un très grand nombre de cas d'utilisation . La fonction publique est très complexe.

Il ne faut pas être désolé. Je n'ai pas les chiffres (je ne les ai pas cherchés non plus !). J'ai fait à la louche. 200 personnes pour un tel projet et sur un telle période, c'est juste... beaucoup trop !.

La question est donc : pourquoi 400 années-homes de "fonctionnaires branquignols" a réussi alors que 2 000 années-hommes de "cadors du privé" a échoué (le tout en ordre de grandeur bien sûr) ? Surtout qu'ils pouvaient prendre l'ancien comme cahier des charges. Mais ils sont partie d'une feuille blanche. En annonçant que, avec de vrais informaticiens, on allait passer à quelque choses de sérieux.

Dans la mesure où les "fonctionnaires" ont fait mieux que des experts, je ne les qualifierai pas de "branquignols", mais plutôt de "débrouillards" Ensuite, un semblant d'explication : j'ai (déjà) vu trop de personnes soit disant experts de SSII ESN qui sortaient... tout juste de l'école ! (je ne jette pas la pierre sur ces personnes. Bien souvent, c'est plutôt l'ESN qui survend ses employés)

J'ai quelques éléments de réponse si cela intéresse.

Pour ma part, ça m'intéresse. Ainsi que la (ou les) source des éléments de réponse, si possible.

[antoine91]

La source : je connais parfaitement tous les gens qui ont participé à EPP ou SIRHEN. Depuis 30 ans.
Et les chiffres que je cite (en ordre de grandeur) peuvent être corroborés par tous les acteurs mais je ne peux pas les citer. Encore moins fournir des documents confidentiels.
Mais je peux expliquer les raisons profondes de cet échec qui était prévisible dés la conception en 2005 - 2007. En ne citant que des données relativement "publiques". Et je ne vais pas résumer 30 ans en un post.

la première cause essentielle pour moi : CapGemini a imposé un socle technique lourd et complexe (entre autres full SOA) et la méthode du grand cycle en V. Avec un usage intensif de toutes les librairies classiques du marché (Hibernate, Spring, JSF, et une foultitude d'autres). D'où l'expression fort juste d'un journaliste : mammouth arthritique.
Le drame est que cela supposait d'avoir une maîtrise d'ouvrage capable de fournir des cahiers des charges parfaits et stables. Avant 1989 (la préhistoire !) la gestion était pour une bonne part relativement manuelle. La MOA contrôlait bien. Mais elle était débordée par le nombre croissant des élèves et disciplines en lycée et collège avec des rentrées de plus en plus catastrophiques. D'où l'arrivée de EPP qui, dans sa première version (15 personnes sur 2 ans, tous développeurs), a résolu l'essentiel de ces problèmes avec Informix 4GL. Et ce logiciel s'est étendu au fil des années. Avec le turn over la MOA a perdu progressivement sa maîtrise en faisant confiance au logiciel. De plus les "débrouillards" connaissait bien le métier et, au fil du temps, mieux que la MOA. Le développement était sans vraie méthode : la MOA fournissait une ébauche de cahier des charges (par exemple le décret dans sa formulation juridique à peine commentée). Le développeur fournissait vite un un premier jet en implémentant l'essentiel et cela permettait à la MOA d'usage de préciser ses besoins itérativement (genre cycles de qq semaines). On arrivait à un résultat consensuel en mettant de coté les parties inutiles et contradictoires.

Mais CapGemini est arrivé avec son monstre et a exigé des cahiers des charges précis et complets plutôt de la part de la MOA stratégique (les grands décideurs) en ignorant souvent la MOA d'usage (les gestionnaires). Il a obtenu des énormes pavés contenant absolument tout et bourrés de fautes et contradictions. Avec des demandes parfois ubuesques que les "anciens" auraient délicatement mis de coté. Et ils ont implémenté tout cela en faisant d'abord rédigé des spécifications générales puis détaillées à partir du cahier des charges. Le tout interminable.
SIRHEN a donc été une succession de tunnels. Et à chaque sortie de tunnel la MOA d'usage (qui avait souvent changé entre temps !) disait : "mais ce n'est pas du tout ce que l'on voulait !". Et CapGemini de répliquer "c'est dans le cahier des charges !". Dialogue de sourds.

A plus.

[Marco46]

Avec un usage intensif de toutes les librairies classiques du marché (Hibernate, Spring, JSF, et une foultitude d'autres).

Pour le web c'est parfaitement obsolète comme stack et depuis au moins 5 ans.

Manifestement il y a un autre problème c'est la non-prise en compte des problématiques du passage client lourd vers client léger. Le web évolue très très vite et les applications doivent impérativement suivre les évolutions des navigateurs sinon c'est un désastre. Cela élève considérablement le niveau technique requis chez les intervenants et oblige ipso facto à fonctionner en mode agile sérieux pour s'occuper de la dette technique au fil de l'eau puisqu'elle s'accumule très très vite.

Merci pour les infos !

[JCD_31]

...

Travaillant actuellement comme prestataire dans un ministère, c'est exactement comme cela que ça se passe.

Pour le web c'est parfaitement obsolète comme stack et depuis au moins 5 ans.

5 ans, c'est généreux, je trouve. Le "service d'approbation" commence à réfléchir de mettre à jour la JDK et Maven au delà de 1.6 et 2.2...

[antoine91]

JCD_31 et Marco46 pointent sur une autre problématique: l'empilage des librairies et leur évolution dans le temps. Avec des problèmes monstrueux de montée de version vu le nombre d'interactions exponentiel. C'est pour cela que l'on hésite à monter de version ... Du coup, on se retrouve très vite dépassé.
Quand le projet a démarré en 2007 l'architecture utilisée (et qui n'a pas bougé) était considérée à l'état de l'art. Mais en 11 ans elle est devenue obsolète d'après Marco46. Alors que l'application n'était même pas encore livrée pour les enseignants ! Car en fait elle ne pouvait pas l'être
Il faut voir que ce logiciel a une durée de vie de 30 ans et plus. EPP a commencé en 1989 et continuera le temps qu'il faudra pour que le nouveau SIRHEN arrive (5 ans, 10 ans, jamais ?). A cette échéance de 30 ans que seront devenus toutes ces librairies ?
Par exemple au début des années 2000 le Ministère a décidé contre l'avis des internes de créér un nouveau logiciel avec le must de l'époque : Oracle, WebLogic cluster, et EJB (2.0 avec quantité de fichiers pour encapsuler une requête).
Quand les EJB ont commencé à montrer leurs limites cela a demandé un travail considérable, dangereux et coûteux pour les éliminer. Et c'était tout petit par rapport à EPP ou SIRHEN.

[Marco46]

Avec un usage intensif de toutes les librairies classiques du marché (Hibernate, Spring, JSF, et une foultitude d'autres).

[...]

Quand le projet a démarré en 2007 l'architecture utilisée (et qui n'a pas bougé) était considérée à l'état de l'art. Mais en 11 ans elle est devenue obsolète d'après Marco46. Alors que l'application n'était même pas encore livrée pour les enseignants !

Ce n'est pas une architecture c'est une stack technique qui permet de mettre en oeuvre une architecture. Et en effet la stack est cramoisie. JSF ... Comment dire, même à 1000e de TJM je refuserais de travailler avec une telle techno parce que ça serait me tirer une balle dans le pied pour les prochaines missions.

Une architecture c'est par exemple SOA ce qui est aujourd'hui parfaitement d'actualité et dont les micro-services ne sont qu'une évolution. Tout le monde chercher à construire une plateforme d'API. Ça date en grand partie du "API mandate" lancé par Jeff Bezos début 2000 qui a abouti à faire d'Amazon le plus gros fournisseur d'hébergement du monde alors que initialement c'était simplement un retailer. Mais bref.

Sur des projets qui ont une telle durée de vie la prise en compte de la dette technique doit être une préoccupation permanente et la qualité technique doit être la priorité absolue. L'espace restant étant alloué au développement du métier.

Le métier doit être intégralement écrit dans le langage principal choisi (Java en l'occurrence) sans aucune dépendance externe à part peut être des libs très génériques qui étendent le langage comme Apache Commons mais en nombre très limité. Cette partie doit être testée unitairement dans les grandes largeurs, elle ne doit posséder aucune I/O, pas de fichier, pas de BDD, pas de webservices, etc ...

Et c'est le rôle des couches externes qui ont ce bloc métier en dépendance d'implémenter les I/O et les relations avec l'extérieur. De cette manière lorsque la technologie évolue il est possible de faire avancer le projet sans toucher au métier.

Tout ça n'a rien de magique, ça s'appelle la Clean Architecture, nommée encore architecture hexagonale ou encore "ports and adapters", cf les écrits de Robert C. Martin, Alistair Cockburn, etc ...

Je ne sais pas si ces notions existaient de manière aussi explicite au démarrage de ce projet (2007 pourquoi pas Clean Code c'est 2009 je crois), elles sembleront probablement triviales aux développeurs les plus expérimentés mais c'est en quelque sorte ce vers quoi il faudrait tendre, en particulier sur des projets stratégique avec une durée de vie importante.

Tout ceci nécessite une qualité irréprochable et donc une compétence maximale. C'est absolument infaisable avec de la prestation de service puisque le modèle économique de ces boites est de vendre le plus cher possible une prestation qui va couter le moins cher possible, donc en prenant un maximum de débutants donc incapables de gérer ces problématiques.

Il est nécessaire de mélanger techniciens et fonctionnels, le personnel ultime étant un bon technicien ayant une bonne connaissance du métier.

Bref, on ne réalise pas un logiciel comme on construit une maison, d'ailleurs ça ne se construit pas ça se grandit. Les anglo-saxons ont bien intégré cette logique par pragmatisme, la structure de l'écosystème français majoritairement dominé par la prestation de service conduit à penser qu'on est pas sorti du sable et que, au moins sur cet aspect, on va vraiment finir par ressembler à un pays du tiers monde dans quelques années.

[antoine91]

Le métier doit être intégralement écrit dans le langage principal choisi (Java en l'occurrence) sans aucune dépendance externe à part peut être des libs très génériques qui étendent le langage comme Apache Commons mais en nombre très limité. Cette partie doit être testée unitairement dans les grandes largeurs, elle ne doit posséder aucune I/O, pas de fichier, pas de BDD, pas de webservices, etc ...
....
Et c'est le rôle des couches externes qui ont ce bloc métier en dépendance d'implémenter les I/O et les relations avec l'extérieur. De cette manière lorsque la technologie évolue il est possible de faire avancer le projet sans toucher au métier.
Tout ceci nécessite une qualité irréprochable et donc une compétence maximale. C'est absolument infaisable avec de la prestation de service.
...
Il est nécessaire de mélanger techniciens et fonctionnels, le personnel ultime étant un bon technicien ayant une bonne connaissance du métier.

Voilà les points essentiels !

Un grand merci Marco46 car ce que tu dis correspond en gros aux conclusions auxquelles j'étais arrivé dans mon petit coin en regardant évoluer SIRHEN.
Mais cet avis est-il partagé par beaucoup de gens compétents en général et en particulier sur ce forum ?
Problème : le métier est embarqué dans le vieil EPP mais dispersé un peu partout dans un grand plat de spaghettis. On peut cependant le dénouer. A condition de partir de EPP avec des gens bivalents comme indiqué : bon technicien ayant une bonne connaissance du métier. Mais c'est une espèce rare, non protégée et en voie de disparition.

tout ceci est très important car si on lit bien la communication du ministre :
première partie : on arrête le déploiement de SIHREN (mais pas SIHREN, la nuance est de taille !)
deuxième partie : on va partir sur de nouveaux concepts (peut être proche de ceux que tu indiques mais rien n'est moins sûr) en réutilisant des briques logicielles du SIHREN abandonné.
Cela permet en fait de continuer sans rien changer !

Après tout il s'agit de la gestion de notre Education Nationale pour nos enfants.

[SQLpro]

Calcul :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
TJM   : 500 €                   500 €
Taxes : 100 €                   100 €
Pilotage projet 20%
   -> côté maîtrise d’œuvre :   100 €
   -> côté maîtrise d'ouvrage : 100 €
Matériels, logiciel 10% :        50 €
---------------------------------------
                                850 €
								
=> 1 750 années/homme

A +

[Grogro]

Quand je vois cette gabegie... j'ai honte.

Je ne comprends pas comment nos représentants peuvent ne pas s'étonner plus tôt de coûts pharaoniques de projets mener. Il a quand même fallu attendre que le projet atteigne plus de 5x le montant initial pour dire stop ! Sans compte que le coût initial est déjà très très élevé.

Il y a de quoi avoir honte de nos gouvernants oui, mais il serait intéressant de comprendre comment on peut se planter dans des proportions aussi bibliques, et pas qu'une fois. En trois tomes, cet auteur propose une ébauche d'explication, que ce soit pour le privé ou le public : https://www.amazon.fr/D%C3%A9cisions.../dp/2070763021

Quand à comprendre pourquoi il faut en arriver à un x5 de dérive budgétaire avant qu'un décideur ait le courage de débrancher le malade en phase terminale... je crois que l'explication la plus simple, c'est qu'aucun cadre n'est réellement responsable du projet, et que personne n'ose prendre une décision, de peur d'être le clou qui dépasse qui se prendra le coup de marteau, préférant renvoyer la patate chaude à quelqu'un d'autre. Jusqu'à ce qu'un politique pose ses couilles sur la table et dise "stop", au risque de se faire lyncher dans les médias pour un merdier qu'il a hérité d'une précédente équipe. "Pour décider, il faut être un nombre impair de personnes, et trois c'est déjà trop" disait Georges "Tiger" Clemenceau.

[antoine91]

Quand à comprendre pourquoi il faut en arriver à un x5 de dérive budgétaire avant qu'un décideur ait le courage de débrancher le malade en phase terminale... .

L'explication est correcte. Une autre excuse : parfois il faut continuer dans la douleur pour aboutir.
Tout cela correspond à 2 proverbes contradictoires :
Il ne faut pas jeter le bébé avec l'eau du bain.
L'erreur est humaine, persévérer est diabolique.

[mach1974]

Donc pour peu que ce soit du mainframe, ils n'avaient qu'à remettre un serveur java en front pour garder la base et / ou faire un parallel running . lol
pour 10 millions c'était fait.

[ddoumeche]

Résumons:

• un client qui a perdu la maîtrise de ses règles métiers et en a sans doute un nombre hallucinant (?). Quand on dit que la fonction publique est trop complexe.
• des spécifications vieilles de 13 ans bourrées de fautes (comme toutes les spécifications) et avec une cible probablement mouvante
• un prestataire qui fait confiance au client alors que le client ne sait pas ce qu'il veut, par définition
• avec un cycle en V classique des très grosses SS2I donc long effet tunnel
• formation de 400 personnes, ce qui retarde le projet de 6 mois - un an pendant lequel le groupe originel de développeurs du projet ne fait rien
• prendre 400 personnes sur un tel projet, ce qui multiplie de manière quadratique (ici au quintuple) les coûts à cause de la communication et de la complexité
• complexité qui se traduit par 5 branches de développement maintenues en même temps

Bref, toutes les erreurs classiques que l'on trouve dans The Mythical Man-Month, l'histoire du développement (mouvementé) d'OS/360. Plus des nouvelles.

Ces 400 personnes ont sans doute du écrire ... 5, 10 millions de lignes de code ? Or je ne sais pas comment une SS2I aujourd'hui peut livrer 10 millions de ligne de code à son client
ont-ils du récrire tous les composants JSF, hardcoder toutes les règles de gestion, faire des milliers de services soap ?
Et si tout est en SOA avec une JVM en 1.6, il n'est guère étonnant qu'il s'agisse d'un mammouth arthritique.

Sincèrement, l'Education Nationale et la DISIC devraient faire un procès à Cap Gemini, pour manquement à son devoir de conseil et logiciel déficient. Pour la forme, pour faire le ménage, et pour fournir des détails croustillants sur le projet au public.

Un grand merci Marco46 car ce que tu dis correspond en gros aux conclusions auxquelles j'étais arrivé dans mon petit coin en regardant évoluer SIRHEN.
Mais cet avis est-il partagé par beaucoup de gens compétents en général et en particulier sur ce forum ?
Problème : le métier est embarqué dans le vieil EPP mais dispersé un peu partout dans un grand plat de spaghettis. On peut cependant le dénouer. A condition de partir de EPP avec des gens bivalents comme indiqué : bon technicien ayant une bonne connaissance du métier. Mais c'est une espèce rare, non protégée et en voie de disparition.

deuxième partie : on va partir sur de nouveaux concepts (peut être proche de ceux que tu indiques mais rien n'est moins sûr) en réutilisant des briques logicielles du SIHREN abandonné.

Qu'est ce c'est EPP (HiPiPie ?) concrètement ? Un ensemble d'exécutables déployé sur 900 sites avec 900 bases de données, exécutables et base de données déclinées en de nombreuses versions non suivies ?

Avez-vous une idée du nombre de modules et de lignes de code déjà livrées ? Il faut voir ce qui est reprenable dans sirhen (quel nom prémonitoire), faire un audit du code, l'internaliser (quitte à recruter des anciens prestas ayant travaillé sur le projet).
Le passer en Java 8 (puis 10) pour commencer, le renommer DORA et changer l'interface pour casser la méfiance utilisateur, optimiser

Que veux tu faire d'autre ?

[antoine91]

Résumons:

• un client qui a perdu la maîtrise de ses règles métiers et en a sans doute un nombre hallucinant (?). Quand on dit que la fonction publique est trop complexe.
• des spécifications vieilles de 13 ans bourrées de fautes (comme toutes les spécifications) et avec une cible probablement mouvante
• un prestataire qui fait confiance au client alors que le client ne sait pas ce qu'il veut, par définition
• avec un cycle en V classique des très grosses SS2I donc long effet tunnel
• formation de 400 personnes, ce qui retarde le projet de 6 mois - un an pendant lequel le groupe originel de développeurs du projet ne fait rien
• prendre 400 personnes sur un tel projet, ce qui multiplie de manière quadratique (ici au quintuple) les coûts à cause de la communication et de la complexité
• complexité qui se traduit par 5 branches de développement maintenues en même temps

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.

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.
Enfin évidemment il faut une RH pour gérer ces personnes : activité, congé, grade, échelon .. Et la paye avec quelques (euphémisme) cas d'utilisation en fonction de l'individu et de son affectation (éventuellement multiple, chacune gérée à part)
Maintenant il y a aussi des algorithmes complexes pour gérer l'avancement de carrière ou la mobilité. Car ce n'est pas une gestion individuelle mais collective. Ressemblant de loin à ParcoursSup. Avec des classements par barème pour comparer les enseignants.
J'ai beaucoup simplifié mais je voulais pas vous assommer.

Tout cela a été réalisé en Informix 4GL à partir de 1989 avec une "petite" équipe de 15-20 personnes (puis un peu plus) avec des livraisons échelonnées à partir de 1990. Jusqu'à maintenant. Et cela fonctionne plutôt bien.
La
Sinon, pour SIRHEN, je vous rassure (?) : Ils se sont contentés d'implémenter la partie RH (faisable par ailleurs avec un ERP), tout le reste, le coeur de métier donc a été mis de côté.

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.

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.

[antoine91]

Donc pour peu que ce soit du mainframe, ils n'avaient qu'à remettre un serveur java en front pour garder la base et / ou faire un parallel running . lol
pour 10 millions c'était fait.

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.
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.
Mais c'est vrai il s'agit de langages guère sexy par rapport à Java. Mais au final pour faire de la gestion plus simple plus efficace et plus productif.
La preuve avec le vieux 4GL (1995), très (trop) limité, l'ensemble du système a été écrit en 400 années-hommes. Alors qu'avec Java version "mammouth arthritique" de CapGemini avec 2000 années-hommes seule une partie a été faite. Tellement bien en plus que le ministre a décidé de ne pas déployer par précaution.
Et Genero est au moins 2-3 fois plus productif que 4GL et pallie à toutes ses faiblesses.

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.
Mais bon quand je dis cela j'ai l'impression de dire des obscénités ...

[Florent.Lebail]

Louvois est arrêté ha Bon(troll)? Les problèmes sont juste réglés. Mais il est toujours en fonction...