IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

L'Éducation nationale décide de débrancher SIRHEN, son logiciel visant à gérer son personnel
Qui a déjà englouti 320 millions d'euros

Le , par Stéphane le calme

94PARTAGES

19  0 
Quelles raisons peuvent justifier l'abandon d'un projet logiciel ?
Des technos qui deviennent dépassées
69 %
Une maintenance difficile
63 %
Les coûts élevés
63 %
Un changement d'équipe
19 %
L'apparition d'une meilleure solution
19 %
Autres (à préciser en commentaires)
13 %
Voter 16 votants
Lancé en 2007, le programme SIRHEN (système d'information de gestion des Ressources Humaines et des moyens) a été présenté comme un programme visant à rénover les systèmes d'information du ministère de l'Éducation nationale pour une meilleure gestion des moyens et du personnel.

Cette solution a remplacé progressivement les applicatifs existants (EPP, AGORA, AGAPE, etc.) et devait couvrir une partie des fonctionnalités aujourd’hui assurées par les applicatifs propres à chaque rectorat ou inspection académique. Le mot d’ordre était « agilité ».

SIRHEN est utilisé pour gérer et payer le personnel :
  • de direction,
  • d’inspection,
  • d’encadrement supérieur.

Aujourd’hui, SIRHEN est utilisé par les gestionnaires du personnel, les hiérarchiques et les administrateurs des systèmes d’information. SIRHEN offre des fonctionnalités de gestion administrative individuelle et collective. La gestion du dossier de l’agent est dématérialisée. Les arrêtés et les documents constitutifs du dossier de l’agent sont désormais gérés au format numérique. Le dossier financier de l’agent et la transmissions des éléments de paye dossier financier (transmission des éléments de paye). Enfin, une politique de droits d’accès permet à chacun d’accéder aux informations dont il a besoin pour assurer ses missions.

Évalué initialement à 80 millions d’euros, son coût a été plusieurs fois réévalué pour atteindre 323,3 millions d’euros en 2017.

Pour éviter de se retrouver face à une crise de l'ampleur de celle de Louvois, le système de paiement des soldes des militaires français arrêté en 2013, le ministère avait d'ailleurs, depuis plusieurs années, restreint son utilisation aux seuls 18 000 fonctionnaires de direction, soit 2 % des effectifs. En clair, SIRHEN assure la gestion administrative de 18 000 fonctionnaires. Or, l’institution emploie plus d’un million de personnes, dont 855 000 enseignants.


Jean-Michel Blanquer, Ministre de l'Éducation nationale

Pour rappel, lancé en 1996, Louvois est entré en service en 2011 après plusieurs réorientations et a tourné à peu près immédiatement à la catastrophe. Salaires amputés - ou augmentés - sans raison, rémunération non versées, centaines de milliers de fiches de paye à ressaisir à la main, sans compter le drames des familles obligées de s’endetter pour boucler les fins de mois.

Jean-Michel Blanquer a annoncé jeudi son intention d'abandonner le programme SIRHEN : « Il apparaît clairement que le programme SIRHEN n'est pas parfaitement adapté aux enjeux de gestion des ressources humaines et technologiques d'aujourd'hui. Par conséquent, j'ai décidé de réorienter notre action vers un dispositif plus agile et plus efficace au bénéfice de notre mission de service public », a expliqué le ministre aux Echos.

Les 500 millions auraient même été atteints si l’exécutif n’avait pas choisi de verrouiller le budget. Une ligne difficile à tenir alors que la baisse de la dépense publique est une priorité du mandat d’Emmanuel Macron.

Les coûts de ce revirement restent à préciser. Car il était déjà question d’opter pour des méthodes agiles l’an dernier, avant même l’élection d’Emmanuel Macron à la présidence de la République. Par ailleurs, certaines briques du programme seront réutilisées.

Il revient à la DSI de l’État, la DINSIC (direction interministérielle des systèmes d’information et de communication), de mettre en oeuvre un dispositif « pilotable ».

Source : Les Echos

Et vous ?

Que pensez-vous de cette décision ?
Avez-vous déjà travaillé sur un projet qui a été abandonné par la suite ? Comment cela s'est-il passé ?

Voir aussi :

Polar Flow, une application de fitness, expose par inadvertance les maisons des agents de renseignements et du personnel militaire
Une étude en Norvège impute la baisse du QI aux facteurs environnementaux, y compris la qualité de l'éducation et l'exposition aux médias
France : le ministère de l'Éducation nationale interdit les sorties de classe Apple, car elles seraient plus à titre commercial qu'éducatives
Amazon embauche plus de personnel technique pour Alexa que Google pour toutes ses activités, son assistant numérique
L'Éducation nationale envoie une partie de l'algorithme admission post-bac... sur format papier, Droit des lycéens demande de l'aide pour l'analyser

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de François DORIN
Expert éminent sénior https://www.developpez.com
Le 23/07/2018 à 8:47
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é.

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.

Comment arrive-t-on donc à plus de 320 millions ? Il faut rajouter (et j'en oublie sans doute) :
  • la rédaction du cahier des charges ;
  • les frais de communication ;
  • les frais de formations (pour l'utilisation du nouveau logiciel) ;
  • les réunions (trop nombreuses et regroupant généralement les mauvaises personnes) ;
  • les frais liés aux ratés et où il faut corriger en urgence les effets (embauche de personnel pour traiter manuellement, il y avait eu le cas pour LOUVOIS) ;
  • etc.


Je ne prends pas en compte les frais d'interopérabilité avec d'autres logiciels, qui sont déjà inclus dans le dev (11 ans pour une équipe de 20 quand même, faut pas pousser ).

Tout ça pour en venir où ? Dans le cas de cuisant échec comme celui-ci, le coût du logiciel en lui-même est ridicule en rapport au gaspillage total. Et même en prenant une équipe de 200 personnes, on serait à peine à 10% dans le cas du calcul effectué plus haut. Pourtant, on ne parle que des échecs du logiciel. Pourtant, c'est plutôt un échec bien en amont... C'est vraiment désolant...

---
* 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...
25  0 
Avatar de Marco46
Expert éminent sénior https://www.developpez.com
Le 23/07/2018 à 11:08
Citation Envoyé par François DORIN
À 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.64 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.
C'est pas tout à fait comme ça que ça se calcule.

TJM 500€ c'est un tarif de dev lambda avec un peu d'expérience sans plus. C'est hors taxes. Donc le prix de facturation c'est 600.

On travaille 217j par an.

Donc le coût de facturation d'un développeur à l'année c'est au tour de 120KE.

Ensuite pour gérer les frais, les entreprises prennent généralement le cout moyen de leur personnel et le multiplie par deux ! Et oui ça m'a étonné à chaque fois que j'ai posé la question mais ça s'est vérifié à chaque fois.

Donc le budget tout compris pour un développeur full time pendant une année c'est 240KE.

Avec 20 personnes à ce tarif là on est à 5 millions d'euros.

Il va de soit que ce calcul de cout correspond à du travail en régie, pas au forfait. Il s'agit donc bien de prendre dans ses propres locaux des ressources pour concevoir et réaliser le projet.

Bon maintenant sur 20 personnes, combien on va avoir réellement de productifs là dedans ? On va avoir au moins 2 managers / CdP / Scrum Master pour gérer les troupes, un responsable hiérarchique en haut de cette pyramide de 20 personnes dont le taf sera de faire les réunions de jointure et de communication avec le reste de l'organisation. Ces gens là ne sont pas facturés à 500€HT par jour. C'est plutôt du 600/700 voire même plus. On peut donc éliminer au minimum 4 devs voire 5 juste pour ces 3 postes.

Ensuite il va bien falloir du concepteur fonctionnel pour rédiger les specs en collaboration avec le personnel sachant de l'EN, là pareil on est sur du TJM un peu plus élevé, enlevons donc 5 devs pour avoir 4 concepteurs.

A ce stade on est à 10 devs, 3 managers / CP, 4 fonctionnels.

Il nous manque au moins un devops pour automatiser les déploiements et gérer les environnements parce qu'on est plus en 2007 et qu'on veut déployer rapido dans l'environnement cible sans avoir à tout se taper à la main. Pareil c'est plus cher qu'un dev lambda.

Il nous faut un PMO pour compter les sous.

Il nous faut au moins 2 leads dev pour gérer nos devs, c'est pareil c'est plus cher.

Disons que devops + PMO + leads dev on enlève 5 devs.

On se retrouve donc en bout de ligne avec :

- 1 directeur
- 2 managers / CdP / Scrum Master
- 1 PMO
- 4 fonctionnels
- 2 leads devs
- 1 devops
- et 5 développeurs.

Voilà, en bout de ligne tu as une feature team pour un an pour 5 millions d'euros et le personnel pour la gérer autour sachant qu'en toute honnêteté dans la durée certains postes sont mutualisables entre plusieurs features team. Au passage, on notera que ce cout serait divisé minimum par 2 si tous les personnels étaient en CDI dans la structure cliente. En effet, un dev full time en CDI c'est pas 12KE par mois mais plutôt 6 voire 5. A 6KE de cout mensuel on est autour de 50KE de brut salarié soit 3000 euros nets, pas vraiment dans les grilles de l'administration je pense

Cette équipe comprends 7 personnes (dev + lead devs) qui vont faire la réalisation pendant que 4 vont produire de la spec et les autres de l'organisation et enfin le devops est un accélérateur / facilitateur.

Bon, à partir de là, de combien d'équipes de ce type on a besoin pour sortir un soft capable de gérer la paie de 18 000 personnes ?

Si on regarde ce qui a été publié sur le scope fonctionnel de l'appli ça fait quand même peur :


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

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.

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.
16  0 
Avatar de scandinave
Membre éprouvé https://www.developpez.com
Le 23/07/2018 à 8:20
Citation Envoyé par redcurve Voir le message
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
C'est ce qui à été fais avec Louvois. C'était du SAP. Sauf qu'il y avais tellement de spécificités que ça n'a pas marché. Je suppose que le problème est le même dans l'education nationale. Le problème c'est qu'on a tellement réduit les effectifs de développeurs au sein des ministères, qu'il sont incapables de prendre en charge eux même un tel projet. Alors même que ce serait la seule solution viable.
10  0 
Avatar de antoine91
Membre régulier https://www.developpez.com
Le 24/07/2018 à 1:12
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.
9  0 
Avatar de Marco46
Expert éminent sénior https://www.developpez.com
Le 26/07/2018 à 15:26
Citation Envoyé par antoine91 Voir le message

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.
7  0 
Avatar de antoine91
Membre régulier https://www.developpez.com
Le 23/07/2018 à 18:53
Citation Envoyé par Marco46 Voir le message
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.
6  0 
Avatar de antoine91
Membre régulier https://www.developpez.com
Le 23/07/2018 à 23:07
Citation Envoyé par François DORIN Voir le message

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.
6  0 
Avatar de fredoche
Membre extrêmement actif https://www.developpez.com
Le 07/08/2018 à 13:08
Citation Envoyé par Grogro Voir le message
Permets-moi de compléter ta phrase : "Il y a vraiment un souci avec l'informatique de gestion en France".
Selon ma propre expérience, pas vraiment :
Au début de ma carrière, j'ai travaillé chez HP Grenoble, en régie pour une petite SSII à l'époque.
J'étais support technique pour l'équipe e-business, qui faisait partie du European Marketing Center. A ce titre, entre autres missions, j'ai accompagné le déploiement d'une solution qui s'appelait Backweb Sales Accelerator. Mon rôle était de faire le lien avec les SI et les équipes HP. Le produit semblait de bonne qualité pour l'interface, très en avance sur certains points, avec notamment une interface web entièrement javascript. Le produit devait servir à de la veille concurrentielle pour les équipes marketing HP.
Ils n'ont jamais sur le faire fonctionner : j'ai vu différents ingénieurs intervenir, français, canadiens, slovènes. Des mecs qui font des "professional services" in english. J'ai mis plusieurs fois la main à la pâte et découvert des trucs dans leurs code coté "crawling" de l'information qui dénotait une qualité fort discutable en back-end.
Au bout d'un an, c'est en grande partie sur mon avis que le projet a été abandonné, un projet à 1 million de francs à l'époque, hors matériel. Ce qui parait dérisoire aujourd'hui, mais quand même. Le truc c'est que rien ne laissait penser que ça allait aboutir...

Peu de temps après je suis passé aux services de localisation pour la reprise du développement d'un projet de workflow de contenus et fichiers entre ces services et les agences de localisation externes. Le projet avait déjà 3 ans et n'avait jamais été réellement fonctionnel. Tel que pensé, il mettait en relation 2 serveurs séparés par le firewall HP, et déjà aucun technicien n'avait réussi à faire fonctionner le service de synchronisation, alors qu'ils suffisait de "socksifier" ce service.
C'était un projet web, le truc avait été développé par une boite qui s'appelait Green informatique de Grenoble si mes souvenirs sont bons. Un truc fait en VB6 avec visual studio, compilé sur une DLL interfacée avec ASP. Un truc complètement à la ramasse, tant pour l'interface, que pour les choix techniques, et d'une complexité... Une doc de 300 pages décrivant des classes que personne n'avait envie de se fader. Des bugs partout, qu'il fallait corriger au sein de VS, et recompiler, réenregistrer la DLL à chaque fois.
En gros un projet fait par des développeurs des années 90, qui n'y connaissait rien au web, qui appliquaient leurs méthodes à ces nouvelles techniques, avec en réalité aucun résultat.
Je suis parti un an après, l'appli fonctionnant, mais nécessitant toujours des évolutions pour répondre aux utilisateurs. Le truc a été repris par SOPRA, ma chef en ayant marre de voir les gens de ma boite partir les uns après les autres parce que le boss ne voulait pas nous payer un peu plus.
Je suis à peu près sur que ce projet n'a jamais réellement tourné en production.

Et arrivé dans ma boite actuelle, j'ai du piloté la fin du développement d'une appli web de GED et workflow qui avait été au départ développé par Himalaya 4-5 ans auparavant. Le projet avait fini dans les mains de la justice, la boite condamnée, une autre boite mandatée pour terminer le boulot, ce dont ils étaient tout aussi incapables. Le résultat était juste "nul", mais bon ça fonctionnait à la fin, alors que dire...?
J'ai depuis tout refait plus ou moins et traine toujours des éléments qui quand je retombe dessus me font rager intérieurement.

Moi je pense que c'est la forme de commercialisation des services informatiques en régie ou au forfait qui pose problème. On vend des spécialistes qui sont souvent des branquignoles. les fameux experts n'en sont pas.

Il n'y en a pas beaucoup qui sont en réalité calés suffisamment en :
- interfaces et leur développement, le front-end avec les outils et langages (le fameux javascript tant honni)
- réseaux, protocoles internet, routages, services, firewalls...
- différents OS et leurs spécificités, sécurité des systèmes...
- dev bak-office, services applicatifs
- dev SGBD et surtout SGBDR avec toute la partie conceptualisation
- problématiques matérielles, hébergement
- toutes les problématiques de sécurité (PKI, OSWAP, pentests,...)
- ...
Le tout avec de l'expérience.
L'expérience, c'est juste impossible avec le jeunisme des SSII.

De vrais généralistes de bon niveau capables d'avoir des visions d'ensemble et suffisamment modestes pour être humbles face aux difficultés
Les fameux full-stacks dont la plupart ici croient encore que ça ne peut pas exister alors que bon dieu pour t'en sortir réellement, tu n'as guère le choix que de maitriser tous ces domaines.

Au contraire tu n'as la plupart du temps que des "experts" qui sont experts dans leur petit domaine, et ne peuvent pas sortir de leur zone de confort, soit par fainéantise, soit par aveuglement et ignorance

Citation Envoyé par ddoumeche Voir le message

Parce des secteurs entiers de l'informaticien n'a pas été industrialisés correctement et que le premier imbécile venu peut devenir ingénieur de développement ? Parce qu'on veut faire des graaaaaaaands projets sans en avoir les moyens managériaux ?
Parce que le middle management est souvent nullissime ? Parce qu'on valorise le brassage de beau papier au détriment de l'expérience et des compétences, comme en quarante ?

Sinon il y a de bonnes boites d'informatique en France : Dassault System, Ubisoft, Criteo, Gameloft, Business Object (ah non, racheté par SAP)

L'expérience des monstres informatiques les plus froids et des fronts les plus chauds.
Ouep surement

J'acquiesce sans problème pour ceux que tu cites, mais ce sont tous des éditeurs, pas des ESN/SSII. Ils vivent de la vente de leurs produits, pas des heures qu'ils vendent.
Et quelque part quand tu vends de la viande et des heures, as-tu réellement intérêt à ce que les projets aboutissent ?

Sinon très intéressant ton lien, merci
6  0 
Avatar de François DORIN
Expert éminent sénior https://www.developpez.com
Le 23/07/2018 à 11:59
Citation Envoyé par Marco46 Voir le message
C'est pas tout à fait comme ça que ça se calcule.
Devant le manque d'info, j'ai fait grossièrement, mais l'idée est là

Citation Envoyé par Marco46 Voir le message

TJM 500€ c'est un tarif de dev lambda avec un peu d'expérience sans plus. C'est hors taxes. Donc le prix de facturation c'est 600.
Ca dépend où. En province, c'est plus qu'un dev lambda. Mais effectivement, il y a fort à parier que la boite est en Ile de France. Donc plus cher. Donc je suis en dessous.

Et effectivement, j'ai parlé HT, car on parle toujours HT pour ce genre de chose. La présence de la TVA ne change rien, car si on la paie d'un côté, on l'a récupère de l'autre (pour les pro en tout cas).

Citation Envoyé par Marco46 Voir le message
Ensuite pour gérer les frais, les entreprises prennent généralement le cout moyen de leur personnel et le multiplie par deux ! Et oui ça m'a étonné à chaque fois que j'ai posé la question mais ça s'est vérifié à chaque fois.
C'est pas pour gérer les frais, mais tenir compte des aléas de dev. Un facteur entre 1.5x à 2x (j'ai même vu 3x une fois !) est effectivement fréquent. Mais ce sont des coups de dev, donc déjà inclus dans la facture. J'ai toujours vu les frais en plus sinon. Et non pas avec un facteur. Mais bon, ça doit dépendre de la politique de la boite !

Citation Envoyé par Marco46 Voir le message
Avec 20 personnes à ce tarif là on est à 5 millions d'euros.

Et on retombe exactement sur le même ordre de grandeur. Ouf ! L'idée était bien de montrer que le dev en lui même ne représentait rien par rapport aux sommes astronomiques en jeu
Pour un calcul précis, il faudrait plus d'information, car pour l'instant, on ne se base que sur des suppositions...

Citation Envoyé par Marco46 Voir le message
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.
Pour ma part, je préfère ne pas savoir...
5  0 
Avatar de antoine91
Membre régulier https://www.developpez.com
Le 23/07/2018 à 18:36
Citation Envoyé par redcurve Voir le message
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.
5  0