France : l'État débourse 300 millions d'euros par an en consommable informatique

Je ne sais plus si c'est dans cette discussion (il y en a tellement qui parlent de l'usage du libre et/ou open source dans l'administration). Mais on disait que le problème avec un logiciel propriétaire (comme Word, par exemple), c'est qu'on était dépendant de son format propriétaire.

Et bien je ne sais pas si c'est nouveau (et si c'est donc une réaction récente de Microsoft), mais j'ai vu pour la première fois cette popup en ouvrant Excel ce matin :

http://img20.imageshack.us/img20/8554/officeodf.png

qui permet (si le lien ne fonctionne pas :aie:) de choisir entre utiliser par défaut le format ODF ou le format propriétaire de MS.

Voilà qui répondrait en partie au problème de dépendance vis à vis du logiciel. Est-ce qu'ils l'ont fait pour répondre aux demandes/besoins de clients tels que le gouvernement? Ou rien à voir?

Oui, c'est une bonne chose, c'est mieux d'utiliser un logiciel non libre qui gère un format ouvert qu'un logiciel non libre qui gère un format fermé.

Mais le fait que le logiciel soit libre apporte d'autres avantages : possibilité de porter le logiciel sur une autre plateforme, pérennité, possibilité d'auditer le code pour en vérifier sa qualité/sécurité, etc.

j'aime bien cet article aussi, même si ce n'est pas tout a fait dans le même sujet, ca a un rapport en terme de dépenses informatique

http://www.challenges.fr/economie/20...-a-l-etat.html

(et puis bon, l'article tape sur Steria, donc j'aime forcément :aie:)

Citation:

---

Alors, pourquoi autant de bugs dans le secteur public ? Selon une enquête de l’Inspection Générale des Finances et du Conseil Général de l’Economie[...], l’administration est moins bien armée que le privé.

---

Franchement, j'en suis pas sûr. Les projets sont gérés tout aussi mal dans le privé que dans le public.

Par contre c'est vrai que j'ai bossé sur Chorus (3 jours) et c'était une horreur. 5 SSII sur le même projet, travaillant sur des parties différentes et plus ou moins ensemble. 2 ou 3 fois le projet a été stoppé en cours de dév pour manque de budget (forcément avec une petite centaine de devs sur le même projet...) d'où pertes de connaissance et tout ce qui s'ensuit.

Bref, une beau projet comme on en voit tant dans l'industrie (des appels d'offres qui font qu'on change de sous-traitant tous les 2/3 ans, un budget mal adapté qui fait qu'on vire des gens ou qu'on néglige toute une partie du projet, ...) mais à plus grande échelle.

Donc le problème vient pour moi de la gestion du projet et en particulier du fait de laisser ça à une équipe externe. Si tout était fait en interne par une équipe qui ne bouge pas tous les 3/4 matins et avec des spécifications relativement stables, il y'aurait beaucoup moins de problèmes.

Je pense qu'on peut taper sur tout le monde

Que dire d'un chef de projet chez LA société Majeure au niveau planétaire
qui sur un outil qui reçois dynamiquement des messages les traite sans aucun intervention humaine, vous dit "Mais vous n'allez tout de même pas mettre de log, ni de suivit des message en production ! vous imaginez pas comment ça va être pénalisant pour les perfs !" l'outil en question étant sans aucune IHM tournant du 4 superdomes HP (4 x (32 proc x 4 coeurs, 16 Go ram))

donc on mets la machine en marche l'outil démarre et plus aucunes info
impossible de savoir ce qu'il se passe, ça marche, ça marche pas, le nombre de messages traiter par minutes ?
la boite noire totale.
après de mois de bataille on obtient des logs
et très contant on vois des "Message remis au partenaire ...."
Mais on se prends aussi des tonnes de stack exception et le truc ne fonctionne pas vraiment.
et en analysant le code (que nous ne devions pas voir on est client clef en main) je découvre des choses comme : écriture d'un log de confirmation avant d’effectuer opération !!!
aucune erreur attrapée aucun message d'erreur circonstancié. les erreur de plus bas niveau qui remontent sans rien pour les traiter.
le top fut "table or view does not exist". pas de nom de table, pas de nom de vue, pas de nom de schéma, pas de connexion, pas de nom de composant. sur un système comptant plus de 100 bases avec quelques 10aine de schémas, des milliers de tables dans chaque, le tout utilisé par des millier de composants différents.

réponse "mais vous le savait quelle vue pose problème quand vous le démarré votre composants!"
en gros j'arrête le centre de calcul des impôts. et je le redémarre composant par composant jusqu’à trouver celui-ci qui pose problème. là je le mets en debug et je relance pas à pas ces 100 000 lignes de code pour trouver l'erreur.

"Mais enfin monsieur, vous ne voulez pas tout de même qu'on gère toutes les erreurs ce ne serait plus possible"
etc.

"on a signé un contrat pour faire un outil qui fait ... dans les règles de l'art. et vous être un c@n qui ne connait rien."

j'en conclus que les règles de l'art dans le domaine de l'informatique vu pas hal c'est de faire une boite noire inexploitable qui fait coredump à la première erreur. et qui va demander une armée d'ingénieurs de chez hal bien sur pour analyser la situation. et vu qu'au cahier des charges il est écrit que c'est du quasi temps réel il faut bien évidement que les dits ingénieurs de hal soit présent 24/24 7/7 in situ et ça mon bom monsieur ça ce paie.

A+JYT

Citation:

---

Envoyé par sekaijin

Je pense qu'on peut taper sur tout le monde

Que dire d'un chef de projet chez LA société Majeure au niveau planétaire
qui sur un outil qui reçois dynamiquement des messages les traite sans aucun intervention humaine, vous dit "Mais vous n'allez tout de même pas mettre de log, ni de suivit des message en production ! vous imaginez pas comment ça va être pénalisant pour les perfs !" l'outil en question étant sans aucune IHM tournant du 4 superdomes HP (4 x (32 proc x 4 coeurs, 16 Go ram))

donc on mets la machine en marche l'outil démarre et plus aucunes info
impossible de savoir ce qu'il se passe, ça marche, ça marche pas, le nombre de messages traiter par minutes ?
la boite noire totale.
après de mois de bataille on obtient des logs
et très contant on vois des "Message remis au partenaire ...."
Mais on se prends aussi des tonnes de stack exception et le truc ne fonctionne pas vraiment.
et en analysant le code (que nous ne devions pas voir on est client clef en main) je découvre des choses comme : écriture d'un log de confirmation avant d’effectuer opération !!!
aucune erreur attrapée aucun message d'erreur circonstancié. les erreur de plus bas niveau qui remontent sans rien pour les traiter.
le top fut "table or view does not exist". pas de nom de table, pas de nom de vue, pas de nom de schéma, pas de connexion, pas de nom de composant. sur un système comptant plus de 100 bases avec quelques 10aine de schémas, des milliers de tables dans chaque, le tout utilisé par des millier de composants différents.

réponse "mais vous le savait quelle vue pose problème quand vous le démarré votre composants!"
en gros j'arrête le centre de calcul des impôts. et je le redémarre composant par composant jusqu’à trouver celui-ci qui pose problème. là je le mets en debug et je relance pas à pas ces 100 000 lignes de code pour trouver l'erreur.

"Mais enfin monsieur, vous ne voulez pas tout de même qu'on gère toutes les erreurs ce ne serait plus possible"
etc.

"on a signé un contrat pour faire un outil qui fait ... dans les règles de l'art. et vous être un c@n qui ne connait rien."

j'en conclus que les règles de l'art dans le domaine de l'informatique vu pas hal c'est de faire une boite noire inexploitable qui fait coredump à la première erreur. et qui va demander une armée d'ingénieurs de chez hal bien sur pour analyser la situation. et vu qu'au cahier des charges il est écrit que c'est du quasi temps réel il faut bien évidement que les dits ingénieurs de hal soit présent 24/24 7/7 in situ et ça mon bom monsieur ça ce paie.

A+JYT

---

tu bosses sur du SAP? :mrgreen:

Ca me rappelle les histoires d'un ami sur certains modules, le même genre de truc

Enfin bon, ca prouve juste une fois de plus que la pré conception est au moins aussi importante que la conception elle meme. Quand la spec est mal foutue, le code risque pas d'être parfait :aie: