Discussion :

[Dendrite]

Antoine, une question m'est venue ce matin au petit déj...
Quel était l'existant numérique dans l'EN avant 1989 ?
Les dossiers agents étaient tout papiers... Minitel ne servait qu'aux mutations (ça c'est le souvenir de la prof que j'étais à l'époque)...
What else ?
L'aide au pilotage, c'était juste des excels ?
Dis, Tonton Antoine, raconte l'EN au temps de Vercingétorix.
Ah, et mon mari de me souffler qu'en tant qu'agent DSI en académie, il a vécu l'installation du client messagerie sur les postes en... 2003.

Écrire les règles de gestion, quelle que soit leur complexité, implique aussi d'écrire explicitement les magouilles, arrangements et autres débilités logiques qui sont dans l'existant actuel. Chaque arrangement doit être explicitement énoncé et doit être explicitement remis à plat et discuté.
Ainsi, il est nécessaire que les fonctionnels prennent ces aspects en compte, et que les clients en discutent... et ils péroreront pendant des éons avant de pouvoir débuter, ou donneront des informations contradictoires..

Bien vu... La relation avec les clients me rappelle parfois ce dialogue de Kaamelott entre Arthur et Perceval :
- Mais quand il t'est arrivé ça, tu étais tout seul ?
- Ben oui !!!
- T'es sûr ???
- Ben oui !!!...................... à part Karadeuc bien sûr............................ et Gédéon...................

Non pas que les interlocuteurs soient bêtes comme Perceval, pas du tout, du tout. Mais le travail, c'est la vraie vie, et la vraie vie, c'est un peu le bordel... Si nos vies étaient merveilleusement logiques sans jamais y déroger, on dirait de nous que l'on est psycho-rigides, à juste titre. Et au boulot, on apporte notre humanité. La plupart du temps, il y a une règle... jusqu'à ce que l'on s'asseye dessus. En base de données de mes applis locales, ça donne : des tables pour les règles "puristes", et une table qui a LA priorité absolue saisie a la mano par le gestionnaire et qui permet de s'asseoir sur toutes les autres consignes. J'arrête tout de suite ceux qui pensent que c'est pour les passe-droits des puissants, ça serait plutôt l'inverse... le plus souvent, c'est pour réparer des injustices flagrantes et introduire un peu d'humanité dans la gestion, la base même des Ressources Humaines. Cette méthode permet au moins de savoir très clairement où l'on en est : là, je suis la règle, là, exceptionnellement, j'y déroge. Exemple concret et récent : Si vous avez un enfant invalide, vous avez quelques minuscules droits supplémentaires, il faut bien sûr apporter le papier qui prouve que cet enfant est invalide. Mais la MOA d'ajouter : "mais ma collègue Monique, que je connais depuis 10 ans, elle et Nathalie, sa fille trisomique... je vais peut etre pas lui demander le papier en question !!!" Voilà le genre d'exceptions auxquelles je fais allusion. Ce qui est génial avec les bases de données, c'est que ça reste, donc les exceptions sont vérifiables, on (on, la hiérarchie ici) peut demander des comptes à un gestionnaire et ça n'est pas la porte ouverte au clientélisme.

Question à la cantonade :
Louvois, autre échec retentissant d'une organisation pourtant réputée pour sa discipline, l'armée, quelqu'un ici a vécu ça de près ? J'ai lu les analyses du début de ce fil, j'ai lu que quelqu'un disait que Louvois était encore en prod... Sans dévoiler les secrets de la Grande Muette, c'est bon d'analyser nos échecs en général, en tout cas les causes profondes des échecs d'une organisation de service public en l'espèce. Vous connaissez le proverbe : "On apprend plus de nos échecs que de nos succès."

[François DORIN]

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".

...

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.

Séparer le métier des solutions techniques, je trouve que c'est une c****rie sans nom et c'est justement ce que dénonce Robert C. Martin dans son billet de blog quand il donne l'exemple du marketing qui fait des choix techniques (en l'occurence, il faut des bases de données relationnels car nos clients le demande).

Bien sûr, il ne faut pas se tromper et bien choisir les solutions en adéquation avec le métier. Dans son billet, il précise que le plus important pour correctement définir et concevoir un logiciel, ce n'est pas les données, mais les cas d'utilisation. Quels seront les cas d'utilisation ? Et de là, découle tout le reste, dont le choix des solutions techniques.

Je suis effectivement d'accord sur le principe. Mais dans la réalité, les choses sont souvent bien plus compliquées. Les cas d'utilisation sont souvent évolutives et il est très difficile, voir impossible, de prévoir quels seront les cas d'utilisations dans 1 an, dans 5 ans, dans 10 ans d'un logiciel.

Les données évoluent aussi, mais souvent moins que les cas d'utilisations, et elles se manipulent aisément. En tenant compte du fait que les données sont importantes car une donnée ne se créée pas, elle se récolte (et donc une donnée perdue est... perdue), il n'est pas étonnant qu'aujourd'hui, la donnée soit mise en centre des systèmes. Les SGBD nous aident justement dans cette tâche de protection des données, en nous assurant de leur cohérence et leur intégrité (en plus de permettre leur manipulation facilement).

Il n'est pas étonnant pour un ingénieur logiciel que le plus important soit... le logiciel. Pour une entreprise, le point de vue le plus important, ce sont les données, pas le logiciel. Un logiciel, ça peut se redévelopper, se changer (avec un coût plus ou moins important). Les données, non.

Concernant la mise en place des règles métiers dans une base de données, les 2 plus gros avantages que je vois sont :

• la base de données est autosuffisante pour sa compréhension (du pain béni pour la maintenance !) ;
• des performances inégalées.

Maintenant, il n'y a pas de solution universelle. Pour ma part, quand je démarre un nouveau projet, je regarde justement différents aspects, notamment :

• les cas d'utilisation, cher à Robert C. Martin. ;
• les données existantes (quand il y en a) ;
• l'environnement technique dans lequel s'intégrera la solution.

[antoine91]

introduire un peu d'humanité dans la gestion, la base même des Ressources Humaines

D'accord. A l'EN (je ne sais pas ailleurs) les entorses à la pure logique et au modèle relationnel ne sont pas des magouilles clientélistes. Des essais souvent malhabiles pour réparer ce que la machine refuse de faire. Mais si on creuse c'est le code au final qui est défectueux, insuffisant, ou mal implémenté. Et c'est le développeur qui doit comprendre cela et améliorer son code. Maintenant, si on veut TOUT implémenter, le coût et les délais vont exploser. Au final un juste milieu : prévoir des mesures dérogatoires avec pourquoi pas quelques tables ou colonnes "poubelles" qui permettent au gestionnaire de s'imposer. Par exemple, à l'EN les barèmes sont beaucoup utilisés et c'est complexe. Mais il y a une colonne "manuelle" et le gestionnaire peut surcharger la valeur calculée. De plus, dans ce genre de cas il faut prévoir un champ commentaire signé, daté, historisé pour permettre au gestionnaire de dire pourquoi.
L'idéal est donc un modèle informatique bien propre, dans les règles de l'art mais permettant de surcharger les données à la main en toute transparence.

Antoine, une question m'est venue ce matin au petit déj...
Quel était l'existant numérique dans l'EN avant 1989 ?

Avant 1989 j'étais prof de maths. J'étais donc de l'autre coté du miroir. Mais j'ai appris indirectement l'histoire en 1989 et donc ce que je vais dire ne sera peut être pas tout à fait exact. De plus, 30 ans après la mémoire peut jouer des tours ...
A cette époque lointaine, il y avait quand même une application nationale GESPER (gestion des personnels avec un acronyme amusant). Elle reposait sur des fichiers plats à l'ancienne arrangés en ligne et colonne. Ces fichiers étaient gérés en C avec les fonctions de base du genre open, lock, seek, read, write, seek. Pour les utiliser quelques procédure du genre : ouvre tel fichier, lit (ou écrit) tel article à tel indice, ferme le fichier.
La clé primaire s'appelait toujours "numart" ou (codart pour les nomenclatures).
Quant au reste il y avait une multitude d'applications locales qui devait (?) utiliser toutes les technologies possibles disponibles mais là j'invente.
Problème : quand l'EN est passé à EPP et au relationnel avec Informix SE et le 4GL (qui était le top de la techno à l'époque) le modèle a été importé tel quel avec quelques joyeusetés du genre :
Toutes les clés ont pour nom "numart" avec l'argument massue "c'est plus simple et on ne risque pas de se tromper". sic ...

Pour faire des jointures cela se complique , certes. Il "suffit" donc d'en faire le moins possible. Par exemple, dans un mouvement, pour stocker les voeux d'un candidat il y dans la table candidat 6 champs ; voe1, voe2, voe3, voe4, voe5, voe6. Pourquoi 6 ? Bien avant GESPER (anneés 60-70 ?) le mouvement se faisait avec des cartes perforées et il restait 6 places sur LA carte associé au candidat. 6 voeux gravés dans le marbre pour l'éternité. L'informatique c'était simple. Et, 50 ans après certains mouvements non rénovés ont encore ce "modéle all-in-one " avec 6 voeux.

On peut en rire mais il faut savoir que si certaines de ces anomalies ont été corrigées , la plupart sévissent encore.
Idem pour les normes de dev.
Lors d'un audit début 2000 un consultant a été surpris (euphémisme) en voyant toutes ces colonnes indicées !
Qu'en pense les développeurs confirmés ici ?

[antoine91]

Les cas d'utilisation sont souvent évolutifs et il est très difficile, voir impossible, de prévoir quels seront les cas d'utilisations dans 1 an, dans 5 ans, dans 10 ans d'un logiciel.
Les données évoluent aussi, mais souvent moins que les cas d'utilisations, et elles se manipulent aisément. En tenant compte du fait que les données sont importantes car une donnée ne se créée pas, elle se récolte (et donc une donnée perdue est... perdue), il n'est pas étonnant qu'aujourd'hui, la donnée soit mise en centre des systèmes. Les SGBD nous aident justement dans cette tâche de protection des données, en nous assurant de leur cohérence et leur intégrité (en plus de permettre leur manipulation facilement).
...
Concernant la mise en place des règles métiers dans une base de données, les 2 plus gros avantages que je vois sont :

• la base de données est autosuffisante pour sa compréhension (du pain béni pour la maintenance !) ;
• des performances inégalées.

Entièrement d'accord, à part la durée : 30 ans et plus pour l'EN.
Les SGBD ont une telle espérance de vie avec éventuellement des upgrade. Par exemple, la base EPP Informix SE (1995) a été migré lors d'un POC en 2016 vers Informix IDS dernière version avec ses trop rares procédures stockées.
Par contre quid du logiciel à 30 ans ?
Pour Java je pense que pour le coeur cela passera. Il me semble que le Java 1.2 (2000 ?) tourne encore sur une version moderne moyennant certes quelques warnings. Je connais des applications 1.2 tomcat (écrites sans librairie à part JDBC) qui tournent sur des JVM récentes en weblogic.

Par contre, comme indiqué plus haut, pour toute l'armada de produits et librairies (Jboss, Hibernate, Spring, JSF ...) utilisées par SIRHEN j'en suis moins sûr. Surtout que certaines sont déjà dépréciées avant la mise en service ! Et que l'upgrade pose des problèmes sans fin de conflits croisés. Telle version du produit A n'est compatible qu'avec telle version du produit B à condition toutefois que le produit C reste dans une version ancienne sinon il faut attendre que C passe de n à n+2 surtout pas prendre n+1. Et puis quand enfin c'est réglé c'est D qui vient mettre son grain de sel. Et, pour couronner le tout MAVEN qui se prend les pieds dans le tapis ...

En conclusion, la base de données, c'est la chose la plus importante et la plus pérenne. Et mettre les règles importantes dedans c'est l'assurance de ne pas les perdre. Et surtout qu'elles restent toujours actives ! Maintenant, on ne peut pas tout mettre : il faut faire des choix pour cibler l'essentiel.

[Marco46]

Séparer le métier des solutions techniques, je trouve que c'est une c****rie sans nom et c'est justement ce que dénonce Robert C. Martin dans son billet de blog quand il donne l'exemple du marketing qui fait des choix techniques (en l'occurence, il faut des bases de données relationnels car nos clients le demande).

Ah bah non ! Pour lui la connerie c'est de ne pas séparer. Sur le passage que tu cites il explique qu'il est lead dev d'un produit qui utilise des fichiers plats pour gérer la persistance et que c'est un marketeux qui lui impose le SGBDR relationnel parce que c'est à la mode alors que le besoin n'existe pas. Et ça le rend fou de voir petit à petit le métier s'implémenter dans des procédures stockées.

Bien sûr, il ne faut pas se tromper et bien choisir les solutions en adéquation avec le métier. Dans son billet, il précise que le plus important pour correctement définir et concevoir un logiciel, ce n'est pas les données, mais les cas d'utilisation. Quels seront les cas d'utilisation ? Et de là, découle tout le reste, dont le choix des solutions techniques.

Pour avoir beaucoup lu et beaucoup vu et écouté son discours, je t'assure que la séparation entre l'implémentation du métier et les solutions techniques, et un SGBDR pour la persistance c'est un choix purement technique, c'est l'alpha et l'omega de sa pensée.

Je suis effectivement d'accord sur le principe. Mais dans la réalité, les choses sont souvent bien plus compliquées. Les cas d'utilisation sont souvent évolutives et il est très difficile, voir impossible, de prévoir quels seront les cas d'utilisations dans 1 an, dans 5 ans, dans 10 ans d'un logiciel.

Justement !

C'est l'alpha et l'omega de sa pensée dans le but de permettre l'évolutivité.

On parle d'un mec qui est à la source des mouvements agiles et software craftmanship et donc du devops ! Il fait parti des fondateurs du manifeste agile (ce qui relève à peu près du Serment du jeu de paume pour le développement logiciel).

Son but derrière c'est de faciliter les implémentations des évolutions du métier indépendamment des solutions techniques utilisées et de permettre la mise à niveau permanente de la technique (payer sa dette au fil de l'eau) sans affecter le métier.

Cela impose une automatisation du test du système, ce qui est ingérable si le métier est dans des procédures stockées. Donc le métier doit être concentré dans la seule partie qui est testable unitairement (au sens de TU développeur, pas TU de QA) : La couche applicative.

la base de données est autosuffisante pour sa compréhension (du pain béni pour la maintenance !) ;

Pour Oncle Bob ce n'est pas le lieu pour faire ça. Lui te fera faire ça dans la couche domaine. Si tu as un SGBDR pour ta persistance, la structure de la base ne sera que le reflet de cette couche domaine, elle ne sera pas le référentiel de vérité.

Tout ça répond à une logique, le but est de livrer plus souvent, plus vite, des morceaux plus petits, en évitant au maximum les régressions, donc avec une automatisation très poussée des tests et des déploiements. Ça c'est le mouvement devops, c'est l'état de l'art actuel.


Ceci dit, j'ai moi aussi eut réalisé des logiciels de gestion où la BDD était le centre de tout, et effectivement, je le reconnais sans problème, ça marche très bien, c'est facile à maintenir, c'est efficace.

Mais, ça ne permet pas d'obtenir un Time To Market compatible avec les exigences de notre époque où les équipes les plus avancées sur ces sujets sont capables de réaliser des MEP tous les jours à la demande.

Alors après tout dépend de ce dont on a besoin. Si un système qui permet de faire une MEP par trimestre est suffisant pour gérer son métier, pas de soucis. Ça sera certainement plus facile (pour le moment) de trouver des développeurs expérimentés sur de la conception de SGBDR que de développeurs expérimentés sur la Clean Architecture et les concepts DevOps, mais c'est clairement une solution passéiste.

IMHO.

[antoine91]

Alors après tout dépend de ce dont on a besoin. Si un système qui permet de faire une MEP par trimestre est suffisant pour gérer son métier, pas de soucis. Ça sera certainement plus facile (pour le moment) de trouver des développeurs expérimentés sur de la conception de SGBDR que de développeurs expérimentés sur la Clean Architecture et les concepts DevOps, mais c'est clairement une solution passéiste.IMHO.

On peut trouver un terrain d'entente. A l'EN il y a peu de procédures stockées et presque pas de contraintes d'intégrité judicieuses.
Pour moi, il est impensable de tout mettre dans la base. Comme le dit Martin la base devient un "Blob" monstrueux (allusion au vieux film ?).
Simplement, on stocke les règles d'intégrité essentielles : un fils doit avoir un père. un budget ne doit pas être dépassé sauf indication explicite. Un découpage temporel en périodes ne doit pas avoir de trous ou de recouvrement. Un échelon doit être entre 1 et n ... Tout cela fait déjà beaucoup mais est essentiel.
De plus, j'ai vu le cas dans SIRHEN et ailleurs de requêtes SQL gigantesques. Qui ont dû, après moult déboires pour les maintenir, être découpées en de nombreuses petites requêtes avec du code glu bien commenté. Correct, facile à lire et à maintenir. Mais avec un nombre d'appels réseau hallucinant. En procédure stockée cela va 10 à 100 fois plus vite.
Comme le dit SQLpro (je parle sous contrôle) une requête élémentaire a un coût en BDD qui se compte en µs et le réseau en ms.

[François DORIN]

Ah bah non ! Pour lui la connerie c'est de ne pas séparer. Sur le passage que tu cites il explique qu'il est lead dev d'un produit qui utilise des fichiers plats pour gérer la persistance et que c'est un marketeux qui lui impose le SGBDR relationnel parce que c'est à la mode alors que le besoin n'existe pas. Et ça le rend fou de voir petit à petit le métier s'implémenter dans des procédures stockées.

On dit exactement la même chose sur le constat, mais avec des mots différents Seule la conclusion diverge. On dit que c'est au développeur (au sens très large, incluant architectecte logiciel, chef de projet, ...) de choisir, pas aux autres (comme le marketing). Maintenant, les dev ont besoins de connaître les besoins métiers pour déterminer au mieux les solutions techniques à mettre en oeuvre. Donc séparer les deux est juste... stupide.

Pour avoir beaucoup lu et beaucoup vu et écouté son discours, je t'assure que la séparation entre l'implémentation du métier et les solutions techniques, et un SGBDR pour la persistance c'est un choix purement technique, c'est l'alpha et l'omega de sa pensée.

Je connais le personnage uniquement de nom. Je n'ai pas eu l'occasion de suivre ses discours. L'implémentation du métier complètement décorrélée des solutions techniques ? J'ai du mal à y croire (même avec la meilleure volonté du monde). C'est comme ça qu'on peut se retrouver avec des fichiers à plat (pour reprendre ton exemple), alors qu'il faudrait un SGBD ! Je pense plutôt que sa pensée est de ne pas mettre la charue avant les boeufs, et que les choix techniques doivent découler des besoins métier et non une solution technologique choisie arbitrairement ("le NoSQL c'est trop tendance, j'y go !", "la blockchain c'est hype", "le cloud c'est merveilleux")) qui doit dicter et contraindre l'implémentation métier.

Justement !

C'est l'alpha et l'omega de sa pensée dans le but de permettre l'évolutivité.

On parle d'un mec qui est à la source des mouvements agiles et software craftmanship et donc du devops ! Il fait parti des fondateurs du manifeste agile (ce qui relève à peu près du Serment du jeu de paume pour le développement logiciel).

Son but derrière c'est de faciliter les implémentations des évolutions du métier indépendamment des solutions techniques utilisées et de permettre la mise à niveau permanente de la technique (payer sa dette au fil de l'eau) sans affecter le métier.

Voilà, là on commence à toucher du doigt les aspects intéressants. Surtout la dernière phrase. Derrière se cachent deux problèmes : évolutivité et maintenance, qu'on pourrait grossièrement résumer en :

• évolutivité : mise à jour du métier (par ex. un nouveau besoin);
• maintenance : mise à jour de la technique (par ex. correction d'un bug).

Il faut pouvoir faire évoluer le métier sans avoir besoin de remettre en cause les choix technologiques qui ont été fait, et il faut pouvoir faire des corrections sans remettre en cause le métier. Est-ce que cela implique une séparation stricte entre choix technologique et le métier ? Sûrement pas ! Sinon, on prendrait toujours la solution technologique qui offre le plus de possibilité. Par exemple, pour le stockage de données, on oublie les fichiers à plat et on impose l'utilisation d'un SGBD (tient, c'est bizarre, il lutte justement pour le contraire...).

Cela impose une automatisation du test du système, ce qui est ingérable si le métier est dans des procédures stockées. Donc le métier doit être concentré dans la seule partie qui est testable unitairement (au sens de TU développeur, pas TU de QA) : La couche applicative.

En quoi est-ce ingérable si c'est dans des procédures stockées ? Les tests ne porteront peut-être plus le nom d'unitaire pour ne pas froisser les puristes, mais il est tout à fait possible de les tester ! Et avec le support des transactions au niveau des bases de données actuelle, c'est même très simple de faire des tests sans avoir ensuite à nettoyer : la BD le fait pour nous ! Au début du test, on ouvre une transaction. A la fin, on l'annule. Le tour est joué.

Pour Oncle Bob ce n'est pas le lieu pour faire ça. Lui te fera faire ça dans la couche domaine. Si tu as un SGBDR pour ta persistance, la structure de la base ne sera que le reflet de cette couche domaine, elle ne sera pas le référentiel de vérité.

Quoi de plus normal pour un ingénieur logiciel ? Un DBA (SQL Pro ??? ) te dirait exactement la même chose pour le SGBDR.

Tout ça répond à une logique, le but est de livrer plus souvent, plus vite, des morceaux plus petits, en évitant au maximum les régressions, donc avec une automatisation très poussée des tests et des déploiements. Ça c'est le mouvement devops, c'est l'état de l'art actuel.

Ceci dit, j'ai moi aussi eut réalisé des logiciels de gestion où la BDD était le centre de tout, et effectivement, je le reconnais sans problème, ça marche très bien, c'est facile à maintenir, c'est efficace.

Mais, ça ne permet pas d'obtenir un Time To Market compatible avec les exigences de notre époque où les équipes les plus avancées sur ces sujets sont capables de réaliser des MEP tous les jours à la demande.

MEP signifie Mise en Production je suppose ?

La séparation ou non métier/techno, et le choix fait derrière (Agile/pas agile) se sont deux notions orthogonales. L'un n'empêche pas l'autre et inversement. On peut faire du DevOps avec un métier parfaitement intégré dans le SGBD (je sais, je le fais !). Et au contraire, cela me facilite mêmes les tests et la mise en prod est ultra rapide. On m'a remonté un bug pas plus tard que ce matin sur un applicatif. 2min après, le bug était corrigé ET en prod, sans redémarrage de l'applicatif (et donc sans perte des sessions, etc...). Le problème était dans une procédure stockée.

[Marco46]

On dit exactement la même chose sur le constat, mais avec des mots différents Seule la conclusion diverge.

Diverge c'est énorme !

On dit que c'est au développeur (au sens très large, incluant architectecte logiciel, chef de projet, ...) de choisir, pas aux autres (comme le marketing).

Oui sur ce point on est d'accord.

Maintenant, les dev ont besoins de connaître les besoins métiers pour déterminer au mieux les solutions techniques à mettre en oeuvre.

Oui on est aussi d'accord.

Donc séparer les deux est juste... stupide.

Il s'agit de séparer l'implémentation du métier de la solution technique, jusqu'à un certain point évidemment.

C'est à dire que si je choisis Java comme écosystème. Je vais implémenter mon métier en Java vanilla uniquement. Donc en J2SE si tu préfères.

Hibernate, le choix du container, SOAP ou REST, etc ... Ça ça relève de la stack technique et c'est là qu'il ne doit pas y avoir de métier. Du tout.

Les couches extérieures qui implémentent les choix techniques dépendent du métier, jamais l'inverse. Implémenter du métier dans une procédure stockée c'est ipso facto faire dépendre le métier d'une solution technique.

Je connais le personnage uniquement de nom. Je n'ai pas eu l'occasion de suivre ses discours.

Si tu as une heure je t'invite à regarder cette petite conférence qui résume assez bien je trouve sa pensée, c'est un bon point d'entrée :

L'implémentation du métier complètement décorrélée des solutions techniques ? J'ai du mal à y croire (même avec la meilleure volonté du monde).

C'est le fondement de la Clean Architecture, appelée aussi Hexagonal Architecture, ou encore Onion Architecture, ou en Ports and Adapters Architecture.

C'est comme ça qu'on peut se retrouver avec des fichiers à plat (pour reprendre ton exemple), alors qu'il faudrait un SGBD !

Pourquoi "il faudrait" ? Git fonctionne avec des fichiers plats et ya pas de soucis. C'est un exemple on pourrait en trouver d'autres.

On utilise systématiquement un SGBD mais ça peut être de l'overkill. Comme tu le dis ça dépend du besoin.

Je pense plutôt que sa pensée est de ne pas mettre la charue avant les boeufs, et que les choix techniques doivent découler des besoins métier et non une solution technologique choisie arbitrairement ("le NoSQL c'est trop tendance, j'y go !", "la blockchain c'est hype", "le cloud c'est merveilleux")) qui doit dicter et contraindre l'implémentation métier.

Oui mais le métier ne doit pas être implémenté par la solution technique. C'est fondamental comme nuance ! La solution technique est utilisée autour de l'implémentation du métier.

Il faut pouvoir faire évoluer le métier sans avoir besoin de remettre en cause les choix technologiques qui ont été fait, et il faut pouvoir faire des corrections sans remettre en cause le métier. Est-ce que cela implique une séparation stricte entre choix technologique et le métier ? Sûrement pas !

Si forcément ! Si tu mets ton métier dans des procédures stockées il va se passer quoi si la quantité de données que tu as à traiter devient telle que ton SGBDR explose ? Tu vas commencer par faire sauter les contraintes d'intégrité et par dénormaliser tes tables puis tu vas finir par vouloir passer à du NoSQL. Si ton métier est implémenté dans ton langage de prog plutôt qu'en SQL tu auras beaucoup beaucoup moins de soucis à sortir ton SGBD de ton système pour y mettre un NoSQL à la place.

Sinon, on prendrait toujours la solution technologique qui offre le plus de possibilité. Par exemple, pour le stockage de données, on oublie les fichiers à plat et on impose l'utilisation d'un SGBD (tient, c'est bizarre, il lutte justement pour le contraire...).

Non on prend ce dont on a besoin à l'instant T. Si ça répond plus au besoin on le change. Si les fichiers plats ça répond au besoin il n'y a aucune raison de passer à du SGBD ou du NoSQL c'est de l'overkill.

En quoi est-ce ingérable si c'est dans des procédures stockées ? Les tests ne porteront peut-être plus le nom d'unitaire pour ne pas froisser les puristes, mais il est tout à fait possible de les tester ! Et avec le support des transactions au niveau des bases de données actuelle, c'est même très simple de faire des tests sans avoir ensuite à nettoyer : la BD le fait pour nous ! Au début du test, on ouvre une transaction. A la fin, on l'annule. Le tour est joué.

Tester une base de donnée dans une intégration continue c'est la misère. Déjà si t'es sur du DB2 tu oublies. Jamais tu n'auras l'autorisation d'exécuter des scripts automatisés sur un moteur de BDD sur lequel tu es facturé à la conso processeur. Ensuite tu peux toujours, dans le cas de java, utiliser du H2 qui est une BDD in memory. Mais dans ce cas tu ne testes plus tes requêtes sur ton moteur mais sur un autre qui ne sera pas celui utilisé en réel.

Enfin c'est beaucoup plus lent à exécuter que du test unitaire pur. Beaucoup beaucoup plus lent. Cf la test pyramid de Martin Fowler (un compère de Oncle Bob) :

Et c'est plus compliqué à installer sur un poste de développeur pour pouvoir faire de l'auto exécution des tests en precommit / prepush dans le sens où souvent les postes de devs n'ont pas la base de données sur leur propre machine mais tapent tous sur un serveur dédié.

Bref, ça pose plein plein de problèmes.

MEP signifie Mise en Production je suppose ?

Oui désolé pour l'acronyme sans la définition.

La séparation ou non métier/techno, et le choix fait derrière (Agile/pas agile) se sont deux notions orthogonales. L'un n'empêche pas l'autre et inversement.

Disons que ça aide d'être sur une clean archi pour vraiment faire de l'agile / devops à fond les ballons, c'est conçu dans ce but.

On peut faire du DevOps avec un métier parfaitement intégré dans le SGBD (je sais, je le fais !). Et au contraire, cela me facilite mêmes les tests et la mise en prod est ultra rapide. On m'a remonté un bug pas plus tard que ce matin sur un applicatif. 2min après, le bug était corrigé ET en prod, sans redémarrage de l'applicatif (et donc sans perte des sessions, etc...). Le problème était dans une procédure stockée.

Je doute que tu ais versionné ta modif, passé cette modif dans ta pipeline d'intégration continue sur la base du tag, puis déployé testé tout ça dans les différents environnements du pipe en jouant les suites de tests de non-régression et toute la batterie pour derrière finir en prod en 2 minutes.

A mon avis tu as pris quelques raccourcis !

La durée entre le commit de dev (donc dev terminé) et la MEP c'est généralement de l'ordre de l'heure, dans les meilleurs de cas c'est plusieurs dizaines de minutes.

Après tu n'as peut être exécuté que le test correspondant au diff entre le tag précédent et ton correctif mais c'est dangereux ! Ca marche quand on est seul ou en tout petit nombre sur un projet mais ça ne résiste pas à la mise à l'échelle.



Petite précision :

- Je ne fais que donner mon interprétation de la pensée générale déployée par des gens comme Robert C. Martin ou Martin Fowler, je peux très bien me tromper même si dans les grandes lignes je pense que j'ai bon .
- Ça ne signifie pas que je suive forcément à la lettre tout ceci, je suis aussi contraint par mes clients mais j'essaie.
- Ça ne signifie pas que ta méthode (ou la vision de SQLpro) soit forcément mauvaise ou que tu fasses mal, on a tous nos contraintes et notre point de vue.


Mais clairement pour revenir au projet SIRHEN qui doit avoir une durée de vie de 30 ans ou plus, je préfère largement mettre mon métier dans un langage à grande durée de vie que je peux faire facilement évoluer au fil de l'eau plutôt que de m'enfermer dans le produit d'un éditeur particulier. Vraiment y pas photo, de mon point de vue !

EDIT : Un podcast court (15mins) en français à propos du sujet.

[antoine91]

Je vous remercie tous les deux et j'ai ma réponse : métier dans la base ou dans l'applicatif il n'y pas unanimité ! C'est au cas par cas.

Pour en revenir à SIRHEN il me semble que le constat est clair : le produit que le ministre a arrêté cumulait les problèmes et devait être stoppé (ouf). Plus tôt cela aurait été encore mieux !
Maintenant, il y un point inquiétant (au début du fil, mais effleuré après):

En d'autres termes, ils veulent remplacer le programme SIRHEN par le programme SIRHEN qui n'aura évidemment pas un coût différent :

Tout vient de la petite phrase :
On va recommencer avec de bonnes méthodes, modernes en réutilisant des briques logicielles faites dans le SIRHEN stoppé.
Problème : elles sont fortement adhérentes à une technique pas très up-to-date (Spring, Hibernate, JSF ...) et implémentent des fonctionnalités pas très proches de l'ancien EPP et donc de la réalité. En tout cas éloigné de l'usage quotidien des gestionnaires.
Pensez vous que le ministre (enfin ceux qui sont derrière) a conscience qu'il va rebâtir sur un champ de ruines ?
Il me semble plus judicieux de repartir de l'existant EPP et de le considérer comme base du cahier des charges sur lequel on travaille avec la MOA utilisatrice.

[Marco46]

Pensez vous que le ministre (enfin ceux qui sont derrière) a conscience qu'il va rebâtir sur un champ de ruines ?

Déjà que je trouve le secrétaire d'état au numérique très limité (pour être gentil) et essentiellement dans la communication, je te laisse imaginer ce que je pense des compétences du ministre de l'EN en la matière et de Macron plus généralement.

Discuter avec ce genre de personnage de stratégie numérique et de développement logiciel c'est comme discuter littérature et techniques d'écritures avec un enfant adulte (faut pas déconner non plus dsl) de niveau cours élémentaire en français.

C'est terrible mais c'est la triste réalité.

[ddoumeche]

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.

Oui mais fusion des bases et Urbanisation progressif, cela peut vouloir dire plein de choses. Et j'ai commencé à ton message entretemps donc n'ai pas vu ton message de 17h37.

Bah il suffit de regarder le "fameux" logiciel APOGEE qui sert à gérer les bulletins des étudiants dans les universités. C'est tellement "bien fait" qu'ils ont fait développer un outil (DIEGO de mémoire) par des étudiants de MASTER pour pouvoir visualiser les UE, les devoirs qui sont dans un parcours...Bref un logiciel in-convivial au possible.

L'utilisation de toutes les ressources informatiques de l'EN, y compris les étudiants, pourrait-être une solution... en plus, ils ne seraient pas payés ...

On peut trouver un terrain d'entente. A l'EN il y a peu de procédures stockées et presque pas de contraintes d'intégrité judicieuses.
Pour moi, il est impensable de tout mettre dans la base. Comme le dit Martin la base devient un "Blob" monstrueux (allusion au vieux film ?).
Simplement, on stocke les règles d'intégrité essentielles : un fils doit avoir un père. un budget ne doit pas être dépassé sauf indication explicite. Un découpage temporel en périodes ne doit pas avoir de trous ou de recouvrement. Un échelon doit être entre 1 et n ... Tout cela fait déjà beaucoup mais est essentiel.

En fait, il n'y a pas de consensus au sein des développeurs sur le fait de tout mettre en base ou pas, selon le langage de prédilections : les uns disent que cela améliore dramatiquement les performances ce qui est vrai, les autres que c'est un enfer à maintenir. Ce qui est vrai aussi car si on peut imaginer de faire assez de tests unitaires coté Java/C#/Genero (?) pour ces procédures, quid du versioning, du refactoring, du debuging et j'en passe.

De plus, j'ai vu le cas dans SIRHEN et ailleurs de requêtes SQL gigantesques. Qui ont dû, après moult déboires pour les maintenir, être découpées en de nombreuses petites requêtes avec du code glu bien commenté. Correct, facile à lire et à maintenir. Mais avec un nombre d'appels réseau hallucinant. En procédure stockée cela va 10 à 100 fois plus vite.
Comme le dit SQLpro (je parle sous contrôle) une requête élémentaire a un coût en BDD qui se compte en µs et le réseau en ms.

Quand on écrit correctement son SQL donc ses requêtes hibernate, cela va aussi 100 fois plus vite.
Ce que tu ne vois pas est que les requêtes SQL gigantesques sont toujours là, dans les procédures stockées. Qu'on peut découper en autant de procédures stockées s'appelant les unes les autres.

Entièrement d'accord, à part la durée : 30 ans et plus pour l'EN.
Les SGBD ont une telle espérance de vie avec éventuellement des upgrade. Par exemple, la base EPP Informix SE (1995) a été migré lors d'un POC en 2016 vers Informix IDS dernière version avec ses trop rares procédures stockées.
Par contre quid du logiciel à 30 ans ?
Pour Java je pense que pour le coeur cela passera. Il me semble que le Java 1.2 (2000 ?) tourne encore sur une version moderne moyennant certes quelques warnings. Je connais des applications 1.2 tomcat (écrites sans librairie à part JDBC) qui tournent sur des JVM récentes en weblogic.

la Compatibilité ascendante est plutôt bien faite. pas sur que le java 1.2 tourne sur une JVM v10 par contre.

Et, pour couronner le tout MAVEN qui se prend les pieds dans le tapis ...

Mais non, Maven est la meilleure invention du monde du software de ces 15 dernières années... tellement que Microsoft l'a copié avec son nuget, une magnifique réalisation elle aussi .....

[antoine91]

Oui, c'est bien là ou est le problème.
Il faut bien voir que le ministre a d'autres chats à fouetter (ex: l'enseignement en primaire). A mon avis, il s'est contenté de transmettre le rapport concocté par ses services. Comme c'est un homme intelligent il l'a quand même analysé superficiellement (manque de temps) et il l'a trouvé cohérent. C'est ce que les journalistes ont retenu : après une demi-douzaine de ministres passifs, de droite et de gauche, en voilà un au moins qui a le courage de stopper l'hémorragie. Au final, c'est plutôt flatteur pour lui.
Tous se passe aux niveaux inférieurs, très haut quand même !
Par exemple, le DP (directeur de programme) actuel est une personne très compétente nommée depuis 2-3 ans et qui a essayé de redresser la barque avec les bonnes méthodes : agilité, devops, etc. Et qui aurait tout à fait sa place parmi les piliers de ce forum. Comme le patron de la DINSIC aussi, mais là j'ai moins d'éléments pour juger. Je présume donc.
Cependant le Titanic avait déjà heurté l'iceberg. Trop de brèches à colmater.

Après tout, il me semble que sur ce forum il y a pléthore de gens très compétents. Et comme il s'agit d'argent public, nous sommes tous concernés contrairement à un logiciel du privé qui dilapide des sous privés.
Comment éviter de renouveler les errements précédents en essayant de réutiliser l'ancien SIRHEN ? Mêmes causes, mêmes effets.
Que dire, que faire ?

[ddoumeche]

Oui, c'est bien là ou est le problème.
Il faut bien voir que le ministre a d'autres chats à fouetter (ex: l'enseignement en primaire). A mon avis, il s'est contenté de transmettre le rapport concocté par ses services. Comme c'est un homme intelligent il l'a quand même analysé superficiellement (manque de temps) et il l'a trouvé cohérent. C'est ce que les journalistes ont retenu : après une demi-douzaine de ministres passifs, de droite et de gauche, en voilà un au moins qui a le courage de stopper l'hémorragie. Au final, c'est plutôt flatteur pour lui.
Tous se passe aux niveaux inférieurs, très haut quand même !
Par exemple, le DP (directeur de programme) actuel est une personne très compétente nommée depuis 2-3 ans et qui a essayé de redresser la barque avec les bonnes méthodes : agilité, devops, etc. Et qui aurait tout à fait sa place parmi les piliers de ce forum. Comme le patron de la DINSIC aussi, mais là j'ai moins d'éléments pour juger. Je présume donc.
Cependant le Titanic avait déjà heurté l'iceberg. Trop de brèches à colmater.

Après tout, il me semble que sur ce forum il y a pléthore de gens très compétents. Et comme il s'agit d'argent public, nous sommes tous concernés contrairement à un logiciel du privé qui dilapide des sous privés.
Comment éviter de renouveler les errements précédents en essayant de réutiliser l'ancien SIRHEN ? Mêmes causes, mêmes effets.
Que dire, que faire ?

Que faire, mais je l'ai dit dans mon avant dernier message.

Je suggérerais bien d'écrire au nouveau DP et à la DINSIC, pour les convier à une présentation de votre POC, presque industrialisable, en le présentant comme une solution salutaire "mais temporaire, le temps qu'une solution de remplacement (en Java bien sur) soit trouvée": il faut mettre les formes et ne braquer personne.
Pour le politique, tout ce qui permet de sauver la barque est bon à prendre.

[Marco46]

Après tout, il me semble que sur ce forum il y a pléthore de gens très compétents. Et comme il s'agit d'argent public, nous sommes tous concernés contrairement à un logiciel du privé qui dilapide des sous privés.
Comment éviter de renouveler les errements précédents en essayant de réutiliser l'ancien SIRHEN ? Mêmes causes, mêmes effets.
Que dire, que faire ?

C'est un problème bien plus large que ce seul projet.

L'état doit se doter d'un service interne de développement logiciel couplé à l'exploitation d'un cloud souverain. La totalité des ressources de ces services doivent être internes. Le recours à des prestataires externes doit être ponctuel et marginal. Ça doit être l'exception et non la règle.

En fait, l'état doit se doter de compétences opérationnelles en numérique parce que c'est stratégique. Se reposer uniquement sur de la sous-traitance ça reviendrait à éliminer entièrement l'armée pour utiliser exclusivement des mercenaires pour sa défense. C'est de la folie pure et c'est pourtant ce que l'état fait pour le numérique.

Ça ne veut pas dire que ces ressources doivent devenir des fonctionnaires, ça veut dire qu'on doit leur proposer des CDI et faire le nécessaire pour les conserver dans la durée. Et il faut prendre des bons, des très très bons, surtout au début. Quitte à les payer 2 ou 3 fois le prix du marché. Et enfin il faut commencer petit, surtout pas avec un mastodonte pareil.

[François DORIN]

Il s'agit de séparer l'implémentation du métier de la solution technique, jusqu'à un certain point évidemment.

C'est à dire que si je choisis Java comme écosystème. Je vais implémenter mon métier en Java vanilla uniquement. Donc en J2SE si tu préfères.

Hibernate, le choix du container, SOAP ou REST, etc ... Ça ça relève de la stack technique et c'est là qu'il ne doit pas y avoir de métier. Du tout.

Les couches extérieures qui implémentent les choix techniques dépendent du métier, jamais l'inverse. Implémenter du métier dans une procédure stockée c'est ipso facto faire dépendre le métier d'une solution technique.

Et c'est là où le point de vue devient subjectif. Qu'est-ce qui fait partie de la stack, et qu'est-ce qui fait parti de l'écosystème ? Pour moi, langage ET SGBD peuvent faire partie tous deux de l'écosystème. On parle bien d'éléments qui sont des pierres angulaires du projet. Une fois le langage choisi, il est bien rare d'en changer, à moins d'une refonte complète de l'applicatif. Il en est de même pour le SGBD. Par contre, si une des contraintes est de pouvoir supporter plusieurs SGBD, alors là c'est bien entendu différent et le SGBD doit être inclus dans le stack et non dans l'écosystème.

Si tu as une heure je t'invite à regarder cette petite conférence qui résume assez bien je trouve sa pensée, c'est un bon point d'entrée

J'essaierai. Mais c'est pas gagné (pas un problème de volonté, mais de temps !)

Pourquoi "il faudrait" ? Git fonctionne avec des fichiers plats et ya pas de soucis. C'est un exemple on pourrait en trouver d'autres.

Moi je ne dis rien, c'est ton raisonnement poussé à l'extrême qui conduit à cette décision Si on veut le maximum d'évolutivité, ce n'est pas un système de fichiers qu'il faudrait derrière GIT, mais un SGBD. Certaines "requêtes" sont aujourd'hui impossible (ou extrêmement coûteuse) à faire sur un dépôt Git.

Oui mais le métier ne doit pas être implémenté par la solution technique. C'est fondamental comme nuance ! La solution technique est utilisée autour de l'implémentation du métier.

Je pense qu'on a une vision différente du métier ici. Arrête moi si je me trompe, mais pour toi, le métier, ce ne sont que les règles de bases régissant les différents objets d'un domaine. Par exemple, pour un compte bancaire, ne pouvoir retirer de l'argent que si le compte est créditeur. Donc en gros, le métier = noyau fonctionnel.

Pour moi, cela va au delà. Les besoins des utilisateurs font parti du métier. Deux applications, avec exactement les mêmes possibilités fonctionnelles (car reposant sur le même noyau fonctionnel par exemple), peuvent avoir des usages métiers très différents en fonction des flux mis en place et des cas d'utilisations. Exemple, le noyau fonctionnel pour gérer des personnes (nom, prénom, date de naissance, adresse, etc...) sera très similaire pour une application comptable que pour une application dans le domaine de la santé. Pourtant, l'utilisation qui va en être faite derrière est très différente (la date de naissance est indispensable dans le domaine de la santé pour l'identito-vigilence par exemple) tandis qu'elle sera le plus souvent facultative dans bien d'autres types d'applications. Et c'est pour cela qu'il est indispensable de bien connaître les besoins des utilisateurs et les cas d'usage pour correctement choisir ses technologies.

Exemple d'un cas où d'un côté on a un noyau fonctionnel, mais où la stack utilisée sera différente en fonction des besoins et des cas d'usage. Une application web. Si elle est classique (multipage) ou monopage (à la mode, surtout avec le mobile), alors l'usage d'un framework comme Angular ou pas est à envisager.

Mais pour le noyau fonctionnel, je suis d'accord avec toi. Sauf que j'inclus généralement la BD dans le noyau dans la mesure où je considère qu'elle fait partie de l'écosystème

Si forcément ! Si tu mets ton métier dans des procédures stockées il va se passer quoi si la quantité de données que tu as à traiter devient telle que ton SGBDR explose ? Tu vas commencer par faire sauter les contraintes d'intégrité et par dénormaliser tes tables puis tu vas finir par vouloir passer à du NoSQL. Si ton métier est implémenté dans ton langage de prog plutôt qu'en SQL tu auras beaucoup beaucoup moins de soucis à sortir ton SGBD de ton système pour y mettre un NoSQL à la place.

Bon courage avant de faire tomber un (bon !) SGBD. Ils sont fait pour manipuler de la données. Beaucoup de données. Faire sauter les contraintes d'intégrité et dénormaliser pour vouloir gagner des performances "à cause de la taille des données" est une simple hérésie et celui qui fait ça à gagner le droit d'être lapidé sur la place publique .

Une technologie a ses limites. Je le concède volontier. Mais l'exemple est foireux. Tu penses réellement que faire un traitement lourd en Java sera possible dans le cas où le SGBD ne peut pas le faire ? Si à la base tu as besoin d'un SGBDR, la réponse est non. Si tu peux remplacer le SGBD par une base NoSQL, c'est que le choix d'utiliser un SGBD était erroné, et alors la réponse est oui. Mais dans ce cas là, c'est une erreur de conception, pas une erreur d'évolution

Non on prend ce dont on a besoin à l'instant T.

Donc il faut tenir compte des besoins, donc du métier et des cas d'usage. Impossible de savoir ce dont on a besoin autrement

Je doute que tu ais versionné ta modif, passé cette modif dans ta pipeline d'intégration continue sur la base du tag, puis déployé testé tout ça dans les différents environnements du pipe en jouant les suites de tests de non-régression et toute la batterie pour derrière finir en prod en 2 minutes.

A mon avis tu as pris quelques raccourcis !

La durée entre le commit de dev (donc dev terminé) et la MEP c'est généralement de l'ordre de l'heure, dans les meilleurs de cas c'est plusieurs dizaines de minutes.

Après tu n'as peut être exécuté que le test correspondant au diff entre le tag précédent et ton correctif mais c'est dangereux ! Ca marche quand on est seul ou en tout petit nombre sur un projet mais ça ne résiste pas à la mise à l'échelle.

J'avoue, j'ai pris un raccourci. Mais c'était un cas d'urgence car cela empêchait des utilisateurs de travailler. Et la modification était vraiment mineure. Et je suis seul dessus

Petite précision :

- Je ne fais que donner mon interprétation de la pensée générale déployée par des gens comme Robert C. Martin ou Martin Fowler, je peux très bien me tromper même si dans les grandes lignes je pense que j'ai bon .
- Ça ne signifie pas que je suive forcément à la lettre tout ceci, je suis aussi contraint par mes clients mais j'essaie.
- Ça ne signifie pas que ta méthode (ou la vision de SQLpro) soit forcément mauvaise ou que tu fasses mal, on a tous nos contraintes et notre point de vue.

Entièrement d'accord. Mais je trouve beaucoup plus instructif d'échanger avec des personnes qui ont une vision différente (et argumentée !) que celle que je peux avoir. Et puis, les forums sont aussi là pour ça, échanger !

Surtout que finalement, j'ai l'impression qu'on n'est pas très loin d'être d'accord. Il y a des incompréhensions, mais qui relèvent plutôt de perceptions différentes de certaines notions (par ex. pour moi, métier != noyau fonctionnel).

Mais clairement pour revenir au projet SIRHEN qui doit avoir une durée de vie de 30 ans ou plus, je préfère largement mettre mon métier dans un langage à grande durée de vie que je peux faire facilement évoluer au fil de l'eau plutôt que de m'enfermer dans le produit d'un éditeur particulier. Vraiment y pas photo, de mon point de vue !

Aussi. C'est pour cela que je fuis les nouveaux langages comme la peste (sauf typescript, car traduit en javascript et que le gain apporté d'un point de vue confort est énorme). La seule exception, c'est le SGBD. J'utilise Microsoft SQL Server (vieux, la première version date d'il y a 30 ans), stable (seul SGBD que j'ai testé jusqu'à présent sans aucun problème de changement de version, et passer de 2005 à 2016 sans rien changer, c'est un vrai bonheur !) et il n'y a pas beaucoup de risque que la solution disparaisse du jour au lendemain.

Bref, je peux dire sans problème à mes clients que la solution, dans 10 ans ou 20 ans, elle fonctionnera encore !

[François DORIN]

C'est un problème bien plus large que ce seul projet.

L'état doit se doter d'un service interne de développement logiciel couplé à l'exploitation d'un cloud souverain. La totalité des ressources de ces services doivent être internes. Le recours à des prestataires externes doit être ponctuel et marginal. Ça doit être l'exception et non la règle.

En fait, l'état doit se doter de compétences opérationnelles en numérique parce que c'est stratégique. Se reposer uniquement sur de la sous-traitance ça reviendrait à éliminer entièrement l'armée pour utiliser exclusivement des mercenaires pour sa défense. C'est de la folie pure et c'est pourtant ce que l'état fait pour le numérique.

Ça ne veut pas dire que ces ressources doivent devenir des fonctionnaires, ça veut dire qu'on doit leur proposer des CDI et faire le nécessaire pour les conserver dans la durée. Et il faut prendre des bons, des très très bons, surtout au début. Quitte à les payer 2 ou 3 fois le prix du marché. Et enfin il faut commencer petit, surtout pas avec un mastodonte pareil.

+1000000000000000000000000000 (mais je n'ai pu faire qu'un +1, contrainte technique oblige, les cas d'usage n'ont pas été pris en compte ici )

[antoine91]

Je suggérerais bien d'écrire au nouveau DP et à la DINSIC, pour les convier à une présentation de votre POC, presque industrialisable, en le présentant comme une solution salutaire "mais temporaire, le temps qu'une solution de remplacement (en Java bien sur) soit trouvée": il faut mettre les formes et ne braquer personne.
Pour le politique, tout ce qui permet de sauver la barque est bon à prendre.

Problème : cela a été présenté en 2016 donc au DP actuel et probablement futur. Solution technique considérée comme excellente. Permettant une transition en douceur avec des livraisons en production régulières, par incrément, permettant de satisfaire la MOA. En Genero d'abord, puis très vite en Java couplé à Genero. Avec un principe de vases communicants.

Mais à l'époque le budget prévu était de l'ordre de 1 million pour démarrer et 10 millions au total pour toute la phase de transition vers Java. En gros car cela aurait dépendu du périmètre des prestations. Solution rejetée à priori car "beaucoup trop chère".
Alors que SIHREN continuait (et continue) de griller 1 million par semaine, avec le résultat que l'on connaît

Sinon, je trouve vos contributions très intéressantes. Si au début de SIRHEN les responsables étaient venus farfouiller sur ce forum on en serait pas là.
Mais il n'est jamais trop tard pour bien faire.

[ddoumeche]

Problème : cela a été présenté en 2016 donc au DP actuel et probablement futur. Solution technique considérée comme excellente. Permettant une transition en douceur avec des livraisons en production régulières, par incrément, permettant de satisfaire la MOA. En Genero d'abord, puis très vite en Java couplé à Genero. Avec un principe de vases communicants.

Mais à l'époque le budget prévu était de l'ordre de 1 million pour démarrer et 10 millions au total pour toute la phase de transition vers Java. En gros car cela aurait dépendu du périmètre des prestations. Solution rejetée à priori car "beaucoup trop chère".
Alors que SIHREN continuait (et continue) de griller 1 million par semaine, avec le résultat que l'on connaît

Sinon, je trouve vos contributions très intéressantes. Si au début de SIRHEN les responsables étaient venus farfouiller sur ce forum on en serait pas là.
Mais il n'est jamais trop tard pour bien faire.

Mais aujourd'hui on n'est plus en 2018, la situation a changée. Il faut donc com-muniquer et si possible avec les bon interlocuteurs. Sinon votre travail terminera à la poubelle ce qui est bien sur dans l'intérêt de certains chez vous.
A toi (vous) de bien les identifier.
Mais il est absolument certain que si vous partez sur un nouveau SINRHEN à l'ancienne, l'EN va se planter de nouveau, méthode à Gillou ou pas. Car s'il faut dépenser 500M plutôt que de trancher entre différentes académies pendant 10 ans pour avoir la paix, certains n'hésiteraient pas. Dans ce cas là, il faudra écrire au canard. Ou faire la révolution.

Si les responsables de SIRHEN étaient venu il y a 10 ans, on leur aurait dit de prendre Java ou PHP ou ColdFusion car c'est le top du must. Et qu'avec un prestataire comme Logica, Cap Gémini ou Sopra, le projet était certain de réussir: les conseillers ne sont pas les payeurs.

[virginieh]

C'est un problème bien plus large que ce seul projet.

L'état doit se doter d'un service interne de développement logiciel couplé à l'exploitation d'un cloud souverain. La totalité des ressources de ces services doivent être internes. Le recours à des prestataires externes doit être ponctuel et marginal. Ça doit être l'exception et non la règle.

En fait, l'état doit se doter de compétences opérationnelles en numérique parce que c'est stratégique. Se reposer uniquement sur de la sous-traitance ça reviendrait à éliminer entièrement l'armée pour utiliser exclusivement des mercenaires pour sa défense. C'est de la folie pure et c'est pourtant ce que l'état fait pour le numérique.

Ça ne veut pas dire que ces ressources doivent devenir des fonctionnaires, ça veut dire qu'on doit leur proposer des CDI et faire le nécessaire pour les conserver dans la durée. Et il faut prendre des bons, des très très bons, surtout au début. Quitte à les payer 2 ou 3 fois le prix du marché. Et enfin il faut commencer petit, surtout pas avec un mastodonte pareil.

Tu es fou ça va complètement a l'encontre de toute l'idéologie de nos gouvernements depuis des années.
Déjà la majorité des ministères n'ont pas de vrais service informatique. Et ceux qui en ont c'est exactement le contraire qui se produit, on confie de plus en plus de missions au privé, ce qui fait qu'on perd la main sur ce qui est produit. Au final ça couté plus cher, on a moins de cohérence entre chaque outil vu qu'ils respectent pas tous la même charte graphique par exemple, c'est plus compliqué à maintenir, mais c'est mieux selon les néo libéraux parce que c'est pas fait par l'état.

[Invité]

Tu es fou ça va complètement a l'encontre de toute l'idéologie de nos gouvernements depuis des années.
Déjà la majorité des ministères n'ont pas de vrais service informatique. Et ceux qui en ont c'est exactement le contraire qui se produit, on confie de plus en plus de missions au privé, ce qui fait qu'on perd la main sur ce qui est produit. Au final ça couté plus cher, on a moins de cohérence entre chaque outil vu qu'ils respectent pas tous la même charte graphique par exemple, c'est plus compliqué à maintenir, mais c'est mieux selon les néo libéraux parce que c'est pas fait par l'état.

Mais puisqu'on te dit qu'un fonctionnaire ne travaille pas et qu'il coûte trop cher...
Alors que dans le privée, tu as la vrai force du pays, ce n'est pas un tas de feignants...

Mais bizarrement, tous les services publics qui sont passés au privée voient leur facture augmentée...

Après, comment tu veux récompenser tes amis hauts placés dans le privée si tu ne fais pas appel à eux ? Ton pote de chez Cap Gemini, faut bien qu'ils puissent nourrir sa famille, ses actionnaires... C'est toujours mieux que de filer un salaire à un fonctionnaire