L'antre des coins - Bural, Bureaux

Yawn

kaze_ — Wed, 06 Aug 2008 15:09:00 +0200

De l'"art" avec Open Office Calc

Y'a des jours comme ça, et y'a des jours tous les jours.

Gestion de projet

kaze_ — Tue, 24 Jun 2008 09:24:00 +0200

Pour tous ceux que la vie de bureau passionne, Lapin vous explique la gestion de projet.

Voilà, c'était juste pour dire, et histoire d'utiliser 15 minutes de boulot à faire tout autre chose que du boulot.

Héritage d'un singleton...

ryune — Wed, 11 Jun 2008 15:46:00 +0000

Dans la vie, on se pose parfois des questions à la con.
Dans la vie d'informaticien, on se pose des question d'informaticien encore plus à la con.

Aujourd'hui, je me pose le problème de l'héritage d'un singleton. Un singleton est une classe tout ce qu'il y'a de plus classique, sauf que l'on s'interdit par pur sadisme de l'instancier plus d'une fois.

Celà donne en Java :

Singleton.java


public class Singleton {
       private static Singleton instance;

       private Singleton() {

       }

       public static Singleton getInstance() {
       	      if(instance == null) 
	      		  instance = new Singleton();
	      return instance;
       }
}

Wah, comme c'est révolutionnaire.
Ce qui est rudement sympathique par contre est la possibilité d'accéder à cette instance de n'importe ou (une sorte de variable globale en mieux forcément).

L'héritage de ce type de classe n'est pas sans poser quelques problèmes.
D'une part, le constructeur est privé, ce qui interdit d'emblée l'héritage. Toute solution ayant son problème, c'est tout naturellement que le mot clé protected existe. Celui ci permet l'accès des membres d'une classe aux classes filles uniquement.
D'autre part, le comportement singleton est implémenté dans des méthodes de classes, statiques et il n'est pas possible d'en hériter.

Boulet.java

public class Boulet extended Singleton {
       private static Boulet instance;

       protected Boulet() {
       	      super();
       }

       public static Boulet getInstance() {
       	      if(instance == null) 
	      		  instance = new Boulet();
	      return instance;
       }             
}

Vous remarquerez donc qu'il est nécessaire de réimplémenter le pattern singleton. Ce n'est pas la mort du petit cheval.
Le petit paradoxe dans l'histoire est que de fait, ma classe Boulet est aussi une classe Singleton. Donc, potentiellement, il peut exister plusieurs instances de la classe Singleton. A défaut de la mort du petit cheval, c'est la mort du design pattern.

Il est possible de faire de même en c++. Mais on peut faire vachement plus mieux encore.
En c++ existe la fantastique notion de template.
Le template est une sorte de préprocesseur ultime surpuissant qui permet en gros de paramétrer une classe par un type quelconque (C'est un peu pas terrible comme explication je sais).

Voici donc mon petit moule de classe singleton :

Singleton.hpp

using namespace std;
#include <stdlib.h>

template <typename T>
class Singleton {
 public: 
  static T * getInstance();

 private:
  Singleton();

 private:
  static T * instance;
};

template <typename T>
T * Singleton<T>::instance = NULL;

template <typename T>
Singleton<T>::Singleton() {

}

template <typename T>
Singleton<T>::~Singleton() {

}

template <typename T>
T * Singleton<T> :: getInstance() {
  if (instance == NULL) {
    instance = new T();
  }
  return instance;
}

Et voici une classe fille d'une des classes générées par ce template :

Boulet.hpp

#include "Singleton.hpp"

class Boulet : public Singleton<Boulet> {
      friend class Singleton<Boulet>;
}

Boulet hérite de la classe template Singleton paramétrée par elle même (encore une variante de l'oeuf ou la poule !).
C'est extrêmement classe et lisible (!?).
Le clou du spectacle est l'utilisation du mot clé friend. Autrement dit, je viens de piétiner le principe même d'encapsulation.
Si c'est pas la classe ça.
Comme quoi, on peut également faire des choses assez moches en c++.

Voilà, je n'ai pas voulu aller plus loin. C'est tout à fait possible de le faire, mais je ne suis pas qualifié pour.

ps : Les classes données en exemple ne font rien mais non seulement, elles illustrent bien la vie solitaire du singleton, mais en plus il est tout à fait possible de les étoffer avec de la volonté.

Quand les stats vous donnent raison

kim — Wed, 23 Apr 2008 21:04:00 +0200

J'ai toujours dit qu'on était payés au lance pierre en France, et particulièrement en province, par rapport au reste.

Les statistiques 2008 pour l'insertion professionnelle de mon école d'ingénieur sont sorties.

Un jeune diplômé, sans expérience, a donc en moyenne actuellement, un salaire plus élevé que le mien. Un promo 2006 a un salaire en moyenne supérieur au promo 2005 qui pourtant a un an de plus.

Plus intéressant, la moyenne salaire sans prime en France est dans les 33K brut, avec primes, 35K. Juste au dessous, on découvre une moyenne (on supprimera les salaires non représentatifs) de 50K sans prime, 60K avec primes. On n'est pas au double, mais presque.

... ...

Pour faire le même boulot...

Après ça, dites-moi pourquoi on resterait en France ?

Difficulté d'ordre comestible

kaze_ — Tue, 15 Apr 2008 17:10:00 +0200

Avoir faim. Avoir des viennoiseries dans son sac à dos. Se dire qu'on les a achetées pour les manger progressivement jusqu'à la fin de la semaine, et pas toutes aujourd'hui. Pas toutes aujourd'hui. Rrrhhggnnn.

Résister stoïquement jusqu'à l'heure de sortie du bureau, parce qu'à la maison y'a plein à manger. Résister. Stoïquement. Rrrhhggnnn.

Et cette grognasse du support technique qui ne cesse de me parler de chocolats. MAIS VOUS AVEZ FINI AVEC LA BOUFFE OUI ? Rrrhhggnnn.

Happy days (yeah, seriously)...

C'est pas parce que je suis prestataire qu'il faut m'esclavager

kim — Thu, 10 Apr 2008 21:32:00 +0200

mini coup de gueule sur le comportement général chez mon client

Le prestataire, c'est connu, c'est l'esclave des grandes entreprises. Le prestataire, à l'instar du salarié "interne", a l'avantage pour le client d'être virable du jour au lendemain, et d'être a priori corvéable à merci. Et donc, dans notre équipe, actuellement sur 13 personnes, le N+1 a choisi de "faire confiance" à 6 prestataires, soit près de 50% du personnel. Tous cadres bien sûr, alors qu'en salariés, il dispose également d'ETAM (moins chers, mais avec heures sup' à payer).

Et donc, récemment, mon N+1 chez le client a remonté à mon manager que, je cite : "il est très sérieux et très impliqué quand il faut, mais il y a quelques fois des semaines où il donne l'impression de faire ses heures puis de partir"... Oui oui, sans honte.

Alors il me semblait que mon contrat de travail stipulait une durée de travail hebdomadaire (de 38h30 par semaine, les RTTs c'est définitivement pas rentable pour le salarié...). Quand je "fais mes heures", je fais donc 38h30, et je me fais reprocher de faire mon travail. Et quand je fais au minimum toutes les semaines 40h, et qu'une semaine par mois, je fais un jour d'astreinte (non payé) et 6 jours de travail, dont le vendredi de 8h à 23h, puis le samedi de 9h à 14h (oui oui, ça fait plus de 45hla semaine, + le samedi compté double) le tout non payé parce que les cadres n'ont soit disant pas d'heures supplémentaires.

Je suis cadre au forfait jour, donc en théorie, oui, pas d'heures sup. Mais un nombre de jours travaillés par an. Que je dépasse (au noir) de 12j par an.

Pour rappel, il faut légalement : - 11 heures minimum de repos quotidien (les vendredis de livraison, je n'ai que 9h de repos) - au moins 24 heures consécutives de repos hebdomadaire auxquelles s’ajoutent les 11 heures de repos quotidien (soit un total de 35 heures) ; (dans le cas des livraisons, je n'ai pas mes 35h) - 6 jours maximum de travail hebdomadaire. (on atteint également le maximum, parfois même, je dois aussi travailler quelques heures le dimanche).

Il faut également 218 jours travaillés, Cette année bissextile avec des jours fériés qui se chevauchent, curieusement, les jours restants n'existent pas, je vais donc travailler plus...

Et quand le client te dit qu'une semaine et demi par mois t'est interdite de congés, que comme ton backup a les mêmes conditions, ça t'interdit techniquement 2 semaines de congés d'affilé...

Non, vraiment, y'a un problème quelque part...

Le bonheur

kaze_ — Thu, 06 Mar 2008 10:39:00 +0100

Le bonheur, c'est la fonction "couleur vers alpha" de Gimp.

Et vous, c'est quoi votre bonheur ?

/kaze_ en pleine découverte de son boulot de webmaster.

GROA - Gestion Rationnelle des Offres de l'ANPE

kaze_ — Mon, 11 Feb 2008 13:48:00 +0100

J'ai enfin mis sur Sourceforge mon outil de gestion de candidatures PHP:MySQL dénommé GROA. Notez le subtil jeu de mots... C'est une "alpha-release" utilisable mais aux fonctionnalités encore embryonnaires. Comme je sais qu'il y a pas mal de développeurs dans le coin, j'en profite pour faire un petit appel à nouvelles idées/fonctionnalités... Ici, sur ce blog, ou bien sur sourceforge !

Le site est accessible ici : http://groa.sourceforge.net/
La page Sourceforge du projet : http://sourceforge.net/projects/groa/

Vi vi, je vais étoffer le site dans les prochains jours. Ca reste une "première release vite fait..."

[OCB©] chroniques de la haine ordinaire, volume 13

kim — Mon, 19 Nov 2007 18:23:00 +0100

L'art de sonder l'insondable avec une indépendance relative

L'affaire date d'il y a un peu moins d'un an. Des problèmes au niveau du moral des employés d'OCB et ses concurrents ont fait grand bruit chez nous. Depuis, la direction a décidé de prendre le problème à bras le corps, et a donc commissionné une société indépendante pour analyser les problèmes, le moral des employés etc.

Indépendante ? Oui, mais... même si j'en attend encore les résultats, on peut déjà douter de l'indépendance de l'étude. Ce matin à l'étage, une personne (de l'étage) est passée pour désigner les personnes qui ont été tirées au sort. Après analyse très courte, on se demande comment le tirage au sort a été fait, ce sont les personnes les plus zens de l'étage qui ont été choisies... Curieuse coïncidence...

En outre, un oubli, et de taille je pense : seuls les employés d'OCB sont sondés, pas les prestataires de société de service. Je gage même que les interimaires ne seront pas sondés... Pourtant, nous constituons près de 50% des gens qui travaillent à notre étage. Et nous ne sommes pas ceux qui sont le moins sous pression...

J'attend les résultats, mais curieusement, je ne me fais pas trop d'illusions...

[OCB©] chroniques de la haine ordinaire, volume 12

kim — Mon, 15 Oct 2007 20:03:00 +0200

Idée reçue numéro 1 : le métier d'informaticien, c'est de se donner du travail.

En partant de cette idée, voici un amalgame de pensées menant à une conclusion : l'informatique, chez nous, c'est une sinécure.

L'idée qui se cache derrière cette fausse vraie idée, c'est que le cycle des versions donne l'impression que l'informaticien travaille dans son coin, et livre régulièrement ses élucubrations, les clients subissant ou profitant les changements. L'informatique, ça n'est jamais que le remplacement des méthodes papier et manuelles par un traitement automatisé. Finalement, sans ordinateurs, on y arriverait aussi. De là découle aussi la seconde idée, vraie cette fois : l'informaticien est là pour prendre le boulot des autres et le donner à des machines. Le progrès fait qu'on a de moins en moins besoin d'intervention humaine dans un processus automatisable.

Pourquoi une idée reçue ? Parce que l'informaticien, il n'est pas là pour travailler pour lui, mais il devrait être là pour rendre délivrer un service à un autre, si possible plusieurs autres, leur ôter les charges laborieuses pour se concentrer sur la partie créative/motivante de leur métier.

Malheureusement, ce n'est pas toujours le vecteur d'innovation du métier, et c'est pour ça qu'on pense qu'un informaticien s'auto-finance en produisant une maquette, des alpha, des beta, des pré releases, des livraisons, puis de nouvelles versions. De la correction de bugs, techniques, fonctionnels, d'IHM. Mais si l'on faisait un sondage, je pense qu'on obtiendrait une toute autre version : une fois développée, une application ne devrait pas être génératrice de "travail". Or dans la presque totalité des grandes applications, le coût global de l'application pourrait se résumer à 20% de développement "utile", et 80% de gestion de plannings et de surdéveloppement. On va appeler un surdéveloppement un développement qui aura été improductif (remplacé par un autre parce que ne convenant pas, ...)

Alors, oui, il y a le progrès technique qui rend obsolète (comment parler d'obsolescence pour un produit fonctionnel à 100% ?) certains développements. Il n'empêche.
Un cycle typique de développement se fait en plusieurs phases, dont maquette, pré versions, et release version. La maquette va servir au client de se faire une idée du produit final, mais aussi d'émettre des doutes sur certains points, proposer des modifications, etc. Une préversion permet de vérifier que dans un environnement proche de la production, l'application fonctionne comme on l'entend. La release, c'est ce qui sera donné au client.

Et c'est là que le bas blesse, la plupart des versions ne satisfont pas le client. Comment faire alors... Proposer des nouveaux développements bien sûr ! Mais d'où vient de dysfonctionnement ? Il se trouve souvent dans l'incompréhension entre le langage du développeur et le langage du client. Il est anormal que les défauts trouvés en production n'aient souvent jamais été même évoqués lors de la démonstration de la maquette. C'est que souvent, cette maquette, tout comme les préversions, n'est jamais montrée aux utilisateurs, le commercial croyant bien faire en pensant pour les utilisateurs.

Aujourd'hui, notre gestionnaire des incidents et changements (suivant les recommendations ITIL) a "évolué". Grosse montée de version. En un jour d'utilisateur, il faut savoir que à notre étage, aucun utilisateur n'a aimé cette nouvelle version. Lenteurs, bugs divers, aucune formation à la nouvelle interface. Et pourtant, aucun retour arrière à l'ancienne version ne sera mise en place, parce que cette version, c'est "le progrès"...

Et vous savez quoi ? L'industrialisateur de l'application, hé bien... c'est la personne qui m'avait jeté la dernière fois. Le monde est petit, vraiment petit.

Note : pour ceux qui se disent qu'une seconde de lenteur, ce n'est rien, dites-vous que derrière, cette seconde risque d'énerver l'utilisateur qui va la subir pour toutes les applications qui se dont dit ça. Et 1 seconde par heure pour 1000 utilisateurs, c'est 7000h de pertes sèches quotidiennes, je vous laisse imaginer le chiffrage à l'année...

[OCB©] chroniques de la haine ordinaire, volume 11

kim — Thu, 11 Oct 2007 19:11:00 +0200

où l'on déprime dans la joie et la bonne humeur, et l'indifférence de tous.

Voilà un mois, j'ai fait la demande d'être muté dans une autre région. Connaissant le contexte de ma mission actuelle, je me dis qu'en six mois, ça devrait pouvoir être bouclé en étant pessimiste.

Il arrive parfois qu'on ait besoin de changer, chez moi il faut avouer que c'est assez fréquent. Sans doute parce que l'informatique n'est pas un métier très bandant, malgré ce qu'on aurait pu vous faire croire pendant vos études. Donc pour casser la monotonie, il faut varier les plaisirs. Et s'il faut savoir faire preuve de générosité vis à vis de son boulot, il ne faut pas que la vie s'y résume, donc parfois l'intérêt de la personne doit je crois tout de même être pris en compte.

Et donc, après avoir obtenu un premier rendez-vous avec mon manager, intéressant et riche en dialogue, nous étions partis pour avancer, un premier rendez-vous avec l'actuel client, pour annoncer la chose et voir un peu où on en est, avait été proposé la semaine qui suivait. Je savais très bien que tout était trop beau pour être vrai, c'est pourquoi je ne me suis pas offusqué outre mesure quand une date fixée 3 semaines après le premier rendez-vous avait été fixée. Deux semaines d'attente supplémentaire ne sont rien dans une vie.

Intermède : je poursuis toujours mes recherches passives d'un autre emploi, et sur deux entreprises intéressées j'ai décroché récemment une promesse d'embauche à confirmer par moi même, dans un mois au plus tard, mais qui serait dans une région qui ne m'enchante guère. Et une réponse type "nous on recrute sur projet, on peut pas vous prendre, mais vous voulez aller là bas, eux recrutent sur profil, on fera parvenir votre CV à notre agence sur place, ils vous recontacteront sans faute". Troisième offre qu'on me fait, de ce type, je n'ai jamais eu d'appel...
Fin de l'intermède.

Il y a des jours où on aurait mieux fait de ne pas se lever. Dès le matin mon chat m'avait prévenu, cette journée, tu vas craquer. Il ne parle pas, mais miaule très bien pour me le faire comprendre.
Début de journée, première nouvelle (bonne !) de possible décalage d'une livraison qui partait dans le mur, tant mieux, j'avais fini ma partie, je pourrai prendre le temps de m'appliquer au reste.
Depuis bientôt un mois, au Brésil, la tension monte, donc sur chaque incident on passe en mode "crise" : résoudre l'incident devient plus que prioritaire. Après pas mal d'efforts, ça commence à se stabiliser, mais ça bouffe les nerfs, vous pouvez pas imaginer à quel point.
Et donc, un incident arrive. Rapidement, je regarde, ça arrive depuis 2h, heureusement, ils dorment encore là bas. Vite résoudre avant de se prendre des appels téléphoniques à rallonge. N'étant que le second sur le processus, le blocage arrivant entre l'envoyeur du fichier à problème et moi, et l'envoyeur ayant un incident précédent au mien, naturellement, je leur envoie le mien pour qu'ils aient toutes les billes pour analyser tout ça. C'est urgent, mais j'oublie de le signaler dans l'incident, pour moi, c'est naturel, mon application et la sienne ont de fortes priorités.

Retour de manger, il est 12h15, l'incident me revient à 12h30 (3h après), sans commentaire autre que "on débloque ce traitement". En même temps, je vois arriver 4 incidents successifs : le traitement n'est pas du tout débloqué. J'ai pas que ça à faire, j'ai sur le feu 3 actions en cours (un audio, deux problèmes autres, et ça qui arrive). L'objectif étant de donner la priorité à la production, je décide de torcher le problème et de tout résoudre : à 12h30, les gens là bas commencent à travailler, ils n'ont encore rien vu, autant que ça reste le cas. Je me connecte à mon serveur, arrêt relance de service préventif, purge de répertoires. Et je me connecte au serveur en amont pour voir où ça en est : blocage complet, il est l'heure de manger, ça aurait trainé. Maitrisant l'application posant problème, je m'en occupe, 2 minutes plus tard, le transfert est de nouveau opérationnel (au lieu de 1h si on avait suivi le circuit classique), sans impact "a priori".

Je dis "a priori" parce qu'à 15h, je me prend un message "dis, c'est toi qui est connecté à notre serveur ?". Honnête, je dis oui. "Bah écoute t'as rien à y faire (vrai), pourquoi tu l'as fait ?". Je répond naturellement que le Brésil a des problèmes et que si ça n'avait pas été fait vite, on serait en crise. Là dessus je me prend une réponse limite injurieuse "puisque vous n'aviez rien à faire sur notre serveur, vous n'avez qu'à prendre la responsabilité de ça, et donc je ne veux plus jamais entendre parler d'incidents venant de vous". Courtoisie, quand tu nous tiens. On s'était toujours tutoyé, voilà qu'elle me prend de haut, me vouvoie, sans chercher à comprendre.

Moi, tout ce que je voulais, c'est rendre service. Je sais que chacun a son périmètre de travail, mais quand on peut, et quand il le *faut*, il faut parfois prendre la responsabilité de le franchir, pour corriger les problèmes de production (impactant par exemple rien de moins que la capacité de se logguer des utilisateurs). Donc oui, j'ai pris cette responsabilité, je l'assume, mais est-ce vraiment une raison pour se faire engueuler quand de son point de vue on n'a fait que rendre service. Si je ne l'avais pas fait, on y serait peut être encore.
Je ne supporte pas la suffisance de certains, mais vu comme elle le prend, je veux bien être bête et méchant, elle n'entendra effectivement plus parler de moi, mais la prochaine fois qu'elle est en crise sur son appli et que ça génère une douzaine d'incidents sur mes serveurs, par heure, comme c'est arrivé une semaine durant, sans que je n'ai jamais aucune nouvelle d'eux, on en reparlera...

Là dessus, mon manager arrive, pour m'annoncer que finalement, on repousse à mercredi parce que pas le temps... L'un plus l'autre, j'ai failli en pleurer devant mon écran. Ca fait un mois que rien n'a bougé, il a renouvelé ma mission jusqu'à fin décembre. Je pense ne pas le signer avant mercredi... S'il croit que je peux attendre, à son tour qu'il attende ! J'ai toujours tout fait à temps, tous mes entretiens, tout ! J'ai toujours cru bon répondre présent quand on avait besoin de moi...
Un mois, sans rien. La passivité pour amasser ce qu'on peut tant qu'on peut. On m'a même proposé "en attendant de changer de région", de faire du boulot en plus. Le job est intéressant, mais ça fait quand même ramasse miettes.

J'en suis à me demander si je ne vais pas renouveler ce que j'avais fait il y a bientôt un an : donner ma démission, sans même avoir de job en vue (je ne me fais pas d'illusion, la promesse d'embauche j'y répondrai probablement par la négative, la région ne me plait pas).

Et merde.

Ah oui ???

kaze_ — Tue, 28 Aug 2007 13:02:00 +0200

Lu dans Le Monde, un journal sérieux qui titre Le casse-tête des relations amoureuses au bureau :

"Et lorsque des sociétés, notamment dans l'informatique, embauchent par vagues des jeunes diplômés qui passent plus de dix heures par jour à leur poste de travail, la logique veut que des couples se forment."

...

Des couples de garçons, sans doute ?!?

Merci, Le Monde, de faire enfin preuve d'une grande ouverture sur les orientations sexuelles alternatives...

Vendanges

kaze_ — Fri, 24 Aug 2007 19:27:00 +0200

Dans la catégorie "choses que vous ne ferez jamais parce que vous êtes ingénieurs informaticiens..."

Trois jours de vendanges avant l'infection fatale. J'avais oublié mon vieil accident de 97 et la fracture fatale du bras droit. A l'époque, je n'avais pas compris ce que l'expert voulait dire par "5% de handicap," maintenant je saisis mieux. A force de soulever les seaux et les cagettes, mon pauvre bras a décidé que, tiens, il était temps de gonfler un peu. Pchoup ! Une vraie tomate. Et ça fait mal, punaise... Les travaux de force, c'est quand même chaud.

Donc, trois jours de vendanges. Lever avant l'aube, partir sur le p'tit vélo (10€ chez Emmaüs) avec la dynamo qui fait dzzz, de nuit sur la route en faux-plant montant qui mène au château. Arriver dans les premières lueurs du jour, ciel rose pour cueillir le rouge. Rencontrer le patron, les contremaîtres, les nouveaux collègues. Observer l'habile négociation de ceux qui ont séché la veille pour ne pas se faire virer. Discuter avec les potes, Y. le rasta qui écume les festivals du sud dans sa Renault Express graffée, F. qui a 37 ans mais en paraît 20 et vit dans un camping-car, de ville en ville (t'as pas peur de te faire choper par la police et ses arrêtés "anti-cabanisation" gars ? Apparemment non...), M. le vieux maghrébin qui boit du vin et mange du porc, et est certainement un meilleur musulman que ses camarades plus jeunes... Découvrir des gens de tous horizons, les reubeus du coin (oui, y'en a qui taffent, n'en déplaise aux fachos, et c'est vraiment sympa de discuter avec eux et d'entrer un peu dans leur culture et leur manière d'être), les gitans (un contremaître un peu gueulard), les routards, les femmes d'un certain âge qui trouvent là un moyen de subsistance car personne ne veut embaucher quelqu'un qui a fait 20 années sabbatiques pour élever ses gosses ; et tant d'autres encore...

Sur le champ, on coupe le raisin, on remplit les seaux, on les vide dans les cagettes, on charge les cagettes sur les porteurs, qui les portent sur les remorques qui font les va-et-vient entre champ et exploitation agricole. Les caractères des gens se révèlent : les bosseurs, les glandus, les resquilleurs, il y a de tout, des rapides et des lents, des endurants et des sprinters, jeunes et vieux, hommes et femmes, le tout sous la houlette des propriétaires de l'exploitation. Pause au soleil, échange de l'eau, palabres sur le bord des vignes, on pique quelques figues chez le fermier voisin.

Fin de journée, déjeuner collectif chez le patron. Toutes les exploitations ne le font pas, mais celles qui le font, c'est une tradition. Bonne bouffe au menu, et vin du cru ! On décompresse, puis chacun repart chez soi... Liens noués, parfois, amitiés qui débutent. Même si je ne suis plus au turbin, j'espère vous revoir mes chers collègues !

[OCB©] chroniques de la haine ordinaire, volume 10

kim — Sun, 29 Jul 2007 22:21:00 +0200

Les vacances selon OCB

(je rappelle bien sûr que je ne travaille pas chez OCB, j'ai pris cet acronyme parce qu'il sonnait bien et parce que je considère ce taff comme une fumisterie)

Vacances. 2 semaines. J'avais posé tout juste 12 jours, histoire de partir l'esprit tranquille, et avoir un jour avant le retour au taff pour me donner le temps de faire mes courses, me préparer mentalement au retour (reprendre mes repères).

Finalement, ne serait-ce pas futile de se payer deux jours de vacances pour être tranquille, quand on n'a même pas droit à cette tranquillité pendant le reste des vacances. Il faut bien avouer que tous les matins j'ai continué à me réveiller aux mêmes heures qu'en semaine. En me levant, le portable du boulot était en face de moi. 24h/24, un téléphone portable pour le cas où il y ait un problème. Une angoisse constante.

Mon père est médecin. Pour lui, les vraies vacances, ce sont des journées sans téléphone, et je crois que c'est en train de devenir la même chose pour moi. Vacances à moitié gâchées par cette chose qui continue à vous relier à votre boulot.

Au final, près de 6h de téléphone, réparties sur 4 jours. Un quart des jours (week end et jour férié inclus).

[OCB©] chroniques de la haine ordinaire, volume 9

kim — Mon, 09 Jul 2007 21:27:00 +0200

Bienvenue dans le pays des branquignols.

Aujourd'hui, 12h de boulot, pour n'arriver à rien. Rien, niet, quedalle. Moi qui m'astreint à ne pas dépasser les bornes des limites, c'est le premier jour où je flippe vraiment pour la pérennité de mes vacances.

Retour en arrière. Début juin. D'un à peu près commun accord, il est décidé de repousser la montée de version majeure de l'année de 2 semaines, pour laisser le temps de préparer. Tant mieux, parce qu'au fond, de toute façon, peu de choses étaient prêtes (alors que tout devait l'être depuis à peu près 2 mois). De mon côté, j'avais la chance de ne pas avoir trop de changements à faire dans mon code, ce qui fait que ma partie (au sens strict du terme) était en réalité bouclée fin février.

Puis, vint le passage en pré production : aucune nouvelles fonctionnalités n'est autorisée, les tests doivent tous être passés avec succès. Tous ? Non, car d'irréductibles binaires résistent encore et toujours à l'envahisseur ! Et encore maintenant on dispose de bugs bloquants inexpliqués. Mais c'est pas grave, on y croit vachement.

Alors, pour faire bonne figure, ces messieurs de la haute confirment la date, parce que... parce que c'est comme ça, et qu'il faudra bien y arriver. En plus, tous les indicateurs sont dans le vert (sauf deux bien rouge vif, mais bon, on les aura corrigé d'ici là hein !)
Et, dans un souci de professionnalisme, et surtout pour me rassurer avant mes vacances, je décide de refaire un test derrière ceux menés par les équipes de dév & les AMOA (assistants à maitrise d'ouvrage, ceux qui font les tests entre autres). Blaff ! Un binaire se vautre. Blaff ! Une variable d'environnement a sauté dans les applications clientes !

Bilan : sur 4 applications, deux sont KO, en plus de celle déjà dans le rouge à cause de problèmes binaires. Bon, on va dire que la variable c'est vite réglable. Le problème qui reste, c'est le binaire. Jetage de coup d'oeil dans les logs. Mais mais mais... Comment ils ont prononcé leur recette ces rigolos ?!! Ca plante sur 98% des traitements !!!

Et là, c'est McGiver en live et speed : 4 jours pour trouver et corriger les deux bugs rencontrés (plus la vie courante, les problèmes en production et tout). McGiver, parce que pour vous aider, vous aurez droit à :

un spécialiste sur l'application, qui est là 50% du temps, et qui n'arrive pas mieux que vous à se dépatouiller avec son application à lui.
un AMOA qui assiste, impuissant, à la déchéance de la montée de version : tout ce qu'il peut faire, c'est mettre en test des données et regarder faire.
vous-même, pauvre indus sur lequel tout ça va tomber, parce que... Parce que c'est son rôle.
un environnement de travail à faire déguerpir n'importe quel développeur/utilisateur sensé. (voir les articles précédents pour comprendre le bordel que c'est).

Et c'est tout. L'art d'OCB (rappel : ce n'est qu'un nom d'emprunt, la boîte n'est pas celle là bien évidemment) consistant à spécialiser au maximum ses informaticiens. Le backup n'est jamais formé, et sur une application critique utilisée par plusieurs milliers de personnes, une seule est compétente (sans compter une boîte extérieure obscurantiste et flemmarde à souhait). Conclusion : une seule personne dans toute la boîte est capable de faire le miracle tant attendu, et celui-ci est en pleine panne sèche.

J'ai peur pour mes vacances... Deux mois qu'elles sont posées, soigneusement, là où ne devait pas y avoir trop d'activité. Deux mois ! Et tout ça pourrait les remettre en question.

Je vous ai déjà dit que je cherchais du boulot ailleurs ?

2008 : une année de truands contre les cadres.

kim — Wed, 04 Jul 2007 19:11:00 +0200

Petit calcul rapide, je me suis posé la question sur le retour de mon boulot du nombre de jours travaillés en 2008... Ami cadre au Syntec, sache que tu vas te faire truander :)

Comme vous le savez tous, l'an prochain, le jeudi de l'ascension tombera le 1er mai. Et on sera en 2008, ce qui signifie qu'on aura 366 jours dans l'année. Formidable non ?

Alors, je me suis demandé s'il n'y avait pas anguille sous roche. Sortez vos calculatrices.

Sur mon contrat (tout du moins), mon nombre de jours travaillé annuel est de 218 jours. L'an prochain, on aura 52 week end plein, soit 104 jours non travaillés (hors astreintes et travail au noir bien sûr). A cela, il faut ajouter 10 jours fériés + 2 jours fériés régionaux (le 31 décembre et le vendredi saint, je suppose qu'un contrat non alsacien aura 220 jours travaillés au lieu de 118, et pour les jaloux, ces jours sont rattrapés par la non obtention de jours d'ancienneté). On arrive à un total de 116 jours non travaillés théoriques. Or deux jours fériés tombent en même temps, donc on descend à 115.
L'année ayant 366 jours, il reste donc 366 - 115 = 251 jours.

J'ai droit à 20 jours par an de congés payés plus 11 RTTs, soit 31 jours. On descend donc : 251 - 31 = 220 jours travaillés effectifs.

Conclusion : je vais me faire truander gentiment de deux jours. Pour un salaire de 30000 euros brut, il faut compter 30000 / 218 * 2 = 275 euros de déficit pour ma pomme, soit pas loin de 25 euros par mois (16 euros, donc deux cinés par mois), ou encore 275 euros qui seront transférés du client à ma boîte, gracieusement. En effet, le client paye au nombre de jours travaillés, et non en nombre de jours annuels. Donc si pendant un an je travaille 220 jours, le client va payer effectivement 220 jours, et je vais toucher ma part : 218 jours.

Pour ceux qui ne sont pas cadres, ils n'auront pas ce problème, étant payés à l'heure et non au forfait.

C'est beau, non ?

kim — Mon, 25 Jun 2007 20:34:00 +0200

Ca faisait longtemps, je vous sentais trépignant d'impatience... "Alors, c'est quand qu'il va nous reparler de son super boulot de rêêêve ?" Bah... Cédons donc à la facilité : on va dire... "maintenant" ?

Et donc, dans un élan de lucidité, et surtout parce que, finalement, tout le monde disait y croire mais personne n'y croyait vraiment, la montée de version prévue fin du mois sera donc repoussée de deux semaines, pour le plus grand bonheur de tous. Certains seront heureux de pouvoir aller aux Eurockéennes de Belfort, là où d'autres verront leurs vacances écourtées de 3 jours, et leur week-end (déjà bien weak, un jour férié en plein week end !) sapé par une mise en prod.

En général, une montée de version, parce que chez nous on sait y faire, c'est des releases mineures, et une bonne grosse release qui tache deux fois par mois (en principe), où on met tout ce qui touche de près ou de loin à un domaine en particulier, à jour. Brutal, mais au moins, on peut "unifier" les ajouts de fonctionnalités. Enfin, c'est ce qu'on croit. C'est aussi une pré-production d'environ un mois, pour tester, éprouver, valider, recetter, l'ensemble des fonctions et améliorations prévues. Là où ils avaient tout compris, c'est qu'à tout précipiter, on aurait eu droit à un jour pour re-tester absolument tout (livraison prévue sous peu d'une mise à jour de bibliothèque essentielle à 95% des projets, donc recompilation de tout ce qui est chez moi). Au moins, on espère avoir deux semaines.

Avec le niveau d'expertise... Heu... Humm... Oui bon... Avec l'organisation qu'on a une personne vous manque, et tout est dépeuplé. Un testeur n'est pas là, un indus qui prend une semaine de vacances, ça peut vous bloquer 4 à 5000 personnes pendant une semaine. Parce qu'elle est la seule personne compétente. Des exemples, on les multiplie ces temps-ci, avec les congés de chacun qui arrivent. J'ai une application qui doit rentrer en production fin de la semaine, utilisant deux process java et un binaire ELF, et on bloque déjà sur le premier des deux process java. Joie, quand on sait que la seule personne pouvant répondre à mes interrogations est injoignable. Sûr qu'il ne sera pas dans le coin de la semaine, et que donc, tout sera repoussé à... Août (bah oui, on est bloqué par la montée de version mi juillet :p)

Du coup, une règle d'or pour pallier ce problème : jamais de gros changement quand l'indus n'est pas là. Moi, j'avais posé il y a deux mois mes vacances. J'avais même pris mon vendredi, pour pouvoir voyager peinard. Ils ne pourront pas me réquisitionner (de toute façon, c'est non, ou alors ils me donnent un mois de salaire de compensation et ils me paient les aller/retour de mes vacances, y'a pas moyen !). Forcément c'est la merde : "ha oui mais t'es le seul à savoir faire ça maintenant, et même si t'es pas là et que tu blindes tout pour qu'on puisse te remplacer sur ça, si y'a un pépin, on l'a dans le cul, donc forcément, ça va pas". Je suis le seul, sur une bonne vingtaine de personnes, à "poser problème". Sauf que si ils décallent, ça ne peut pas être avant septembre (au moins), et ça, ça le fait pas, mais alors vraiment pas :)

Donc, impasse. J'en connais qui vont passer de bonnes semaines avant leurs vacances...

kim — Thu, 15 Mar 2007 21:13:12 +0000

De la chance d'avoir du boulot... Ou pas

Aujourd'hui, point hebdomadaire au sein de l'équipe, pour voir un peu où chacun en est, où on va. Une heure, une douzaine de personnes. Une liste d'actions à faire (hors planning en général) est faite, avec pour chacune, une personne responsable. Chacun passe à son tour, dire où il en est. On gère nous même l'action, il faut juste dire que ça avance.

Or donc, une par une, les actions défilent. On suit le point sur le vidéo projecteur, un fichier Excell organise les choses. Un délai, un titre, la liste des dates clés, un sommaire/résumé, des commentaires, un réalisateur principal. Derrière ce fichier, posé de manière anodine, une page donnant pour chacun les plannings prévisionnels. De 0 jour par semaine prévus sur des activités financées, à 5 (c'est à dire du full time, on n'a pas le temps de faire autre chose).

Furtivement, au hasard des alt-tab, j'aperçois le planning des autres. Etonné. Certains trainent avec près de 2jours prévus, par semaine, jusqu'à fin mai. Ca leur laisse le temps de régler les choses de la vie courante (genre un incident qui passe, on peut le gérer. Gestion de projets, etc. Tout ce qui n'est pas "financé").

Ma ligne était celle du bas. Seule à être pleine jusqu'à fin mai. Cette semaine, j'ai réussi à baisser ma charge à 5J. Mais en moyenne, je vais tourner à 6J prévisionnels, par semaine, pendant 3 mois. Auxquels il faut ajouter la vie courante, qui est très loin d'être négligeable (par exemple, cette semaine, j'ai déjà fait 2J de vie courante, qui viennent amputer les 5J déjà planifiés pour d'autres taches).

Organisé ? Au maximum possible. La vie courante, avant tout. Les crises, aussi. Et puis, refuser toute réunion non essentielle. Juste lire le compte rendu, pour se dire que mon dieu, ça va encore me retomber dessus. Puis, gérer les actions urgentes, c'est à dire celles planifiées qui ont un très court délai (genre, la journée). S'il y a un trou de 5 minutes, vite vite, en profiter pour faire une doc. En général, ça suffit pour l'écrire. Il faut doubler le temps pour la gestion (genre, bouger le cul de ceux qui doivent la valider, parce qu'elle est urgente à mettre en place, mais c'est moins urgent que d'autres choses).

A l'arrivée, vous l'aurez compris : je vais devoir travailler samedi et dimanche. Pour récupérer des actions à faire pour le week end et que je n'aurai pas eu le temps de faire. Gratuitement.

Si c'est pas beau !

PS : mon prédécesseur avait de jolis plannings aussi : pour 1h30 de réunion, on lui accordait 0.1J. Faites le calcul. Alors, finalement, je ne me plains pas, ça sera pire sous peu.

kim — Mon, 19 Feb 2007 18:52:45 +0000

Aujourd'hui, une journée classique... Au pays de Candyyyyyyyyyy !

Rappel : je ne travaille bien évidemment pas pour OCB, c'est un sigle pour ne pas citer mon véritable donneur d'ordre (le client de mon employeur)

Lundi matin. J'arrive, je me pose devant ma machine, me logue avec mon super identifiant anonymé (tout le monde n'est qu'un numéro, c'est pour rendre le service super plus personnel). Et donc, je me connecte à mon super clickodrome pour voir les incidents qui sont arrivés. Je lance mon Lotus Notes (mon dieu mais quelle horreur ce truc...). 80 mails. 10 minutes plus tard, même constat que tous les matins : rien d'intéressant. Mais il faut quand même tous les parcourir, c'est comme ça. Au niveau des incidents, rien de bien folichon, 3/4 classiques, rien de plus, ni de moins.

Je regarde alors le bulletin d'information du jour. Que vois-je ? kwak a planté pour la première fois (enfin, disons plutôt qu'il apparaît dans le bulletin pour la première fois). La minute qui suit, mon chef n+2 arrive, faisant le tour de l'étage pour dire bonjour, et saute sur mon prédecesseur "dis donc, y'a eu un incident grave là, on a appris ça au 6è, faudrait que tu regardes" et file voir mon n+1. Qui a immédiatement rappliqué : "dis donc, j'viens de me faire tirer les oreilles par Machin (mon n+2 donc), c'est la merde ! En plus -regard vers celui qui était d'astreinte- l'astreinte n'a pas été respectée, il a répondu 1h30 après l'appel -au lieu de 1h15, sachant que l'incident en question aurait trainé 5h sur le bureau avant qu'on ne songe à l'appeler...-"

On passe toute l'équipe en mode crise -c'est un terme pour dire : tout le reste passe ultra secondaire, 4000 personnes attendent de pouvoir travailler, mais toi, c'est du hors budget, donc faudra que tu rattrapes tes heures et c'est pas comptabilisé. Youpi. On regarde : bah non, rien de notre côté, c'est clairement pas nous. On se regarde : "c'est sûrement les dev". Réunion d'urgence : 10 personnes dans le bureau de n+1 : tous les chefs de sous fifres sont là. Décision de réunion à 11h, puis une autre à 13h, puis 15h30 et 17h, pour faire des points d'avancement.

On revérifie : toujours rien, pas même sur les serveurs secondaires. Bon, on passe à nos "occupations habituelles". Réunion suivante : c'est les dev, ils ont fait un update sans clause where, ils ont banané un petit millier de données, et ils ont commencé à les récupérer... Bah voilà !

Fin de la réunion, mon n+1 me demande :
"y'a quelque chose qui m'inquiète, tu disais que tu avais pas mal de boulot et que ça t'inquiétais parce que quand Truc ne sera plus là tu en auras encore plus. Pourtant, tu pars au métronome (j'embellis ses propos) tous les jours. Je ne sais pas si tu es aux 35h ou pas, mais moi je paye pour une prestation, donc si pour la faire tu dois faire plus d'heures, il faudra bien les faire.
- Oui mais là je co-voiture ces temps-ci, je peux pas décider pleinement de mes horaires.
- Bah à ton co voitureur de s'adapter à tes horaires. Si c'est des questions de logistique, c'est à régler avec ton manager.
- C'est temporaire de toute façon." (s'ensuivent des banalités).

Oui, c'est temporaire. Je compte bien partir. Le plus tôt possible. Sauf qu'il a touché LE point intéressant : je suis effectivement aux 35h (+2h pour avoir mon RTT par mois). Et je ne fais pas plus. Je fais donc mes 7h20 (en moyenne) par jour, + des extras un jour par semaine pour m'amener à 37. Et je ne FERAI pas plus. Quand on n'aime pas, on compte. S'il ne sait pas compter son budget, à lui de s'adapter. Quand on voit qu'il alloue 1/10 de journée à un collègue pour 1h30 de réunion (oui oui, ça fait des journées de 15h), on comprend qu'il n'a rien compris.

En plus, je travaillerai bénévolement 4h30 de plus vendredi (7h30 22h30, soit une journée de 12h avec 2h de pause repas, parce que je compte large), + une astreinte à domicile le samedi (toute la journée), avec conférence audio permanente, et opérations à faire régulièrement (100% dispo donc).

Le souci c'est que :

rien de tout ça n'a été écrit sur papier/négocié/validé. Simplement, oralement, je ne devais pas avoir d'astreintes.
Les conditions de travail restent déplorables.
Je ne peux rien dire, sauf pour me mettre mon manager, mon chef d'équipe chez OCB, mon n+2, et mon prédécesseur (qui compte sur moi pour ne pas partir avant mai) sur le dos.

Je HAIS ces journées. Sauf que c'est tous les jours pareil.

L'informatique, ce pis-aller des entreprises.

kim — Tue, 13 Feb 2007 22:54:42 +0000

Mini plaidoyer pour une informatique libérée de toutes ses contraintes.

Savez-vous pourquoi j'aime l'informatique ? Ou plutot devrais-je je voudrais aimer l'informatique. Parce que c'est un domaine d'innovation, qui mérite d'être sans entraves. L'informatique, c'est proposer une alternative au papier crayon et à l'huile de coude. C'est simplifier la vie des gens. Des utilisateurs. Des travailleurs.
Alors, quand une avancée est possible, on se doit de l'adopter, quand elle apporte un plus. Parce qu'elle entraine le contentement de l'utilisateur. Mais voilà, de toutes mes expériences passées et présente, je n'ai pas encore trouvé l'accomplissement. Ce qui fait croire à l'informaticien qu'il accomplit un travail utile.

Qu'est-ce que l'accomplissement dans le travail ?

C'est un concept très subjectif, assez personnel, qui fait qu'une personne sait qu'elle est à sa place, et qu'elle s'y plait. Dans mon cas, cela revient à aimer ce que je fais, savoir que je suis utile à une cause quelconque (économique, écologique, ou autre). Il faut pour cela que je puisse constater ce à quoi j'ai contribué. Par exemple, si je fais un site Internet, il me faut voir le produit final. Pouvoir me dire : je suis fier de ça. J'y ai contribué. Ce site, c'est un peu de moi.
Je crois que c'est ça. Il faut pouvoir etre fier de son travail. Cette fierté peut etre purement égoiste, mais l'approbation de l'utilisateur peut y contribuer fortement.

J'ai travaillé dans une petite SSLL. C'est une société de service en informatique orientée logiciels libres. L'expérience que j'ai pu en tirer, c'est que la gestion d'un projet est primordiale pour obtenir un bon résultat. C'est d'ailleurs ce qui faisait que la quasi totalité des projets réalisés n'étaient jamais bons. Ou plutôt qu'ils ne permettaient pas d'en etre fier.
J'ai travaillé pour une première entreprise, où j'ai appris que le développement le plus efficace est souvent celui qui avance. Celui qui, contre vents et marées, arrive à progresser. Innover pour progresser. Malheureusement, j'y ai appris une triste réalité également : l'innovation est un levier économique qu'on a tendance à utiliser à tort : en baissant l'innovation et la R&D, on croit diminuer les charges et les dépenses, alors que déjà à court terme, le résultat s'avérait catastrophique : sans innovations, l'entreprise passe de leader à fabricant de solutions "sans fonctionnalités, mais cheap". J'ai eu la chance d'avoir pu y travailler à ma guise, et je crois pouvoir etre fier de mon résultat. Malgré tout, la volonté anti-innovation a pris le dessus.
Dans l'entreprise où je suis actuellement, je crois pouvoir dire que j'atteins le summun de l'emploi sans intéret. Je suis chargé de l'industrialisation d'un produit (sous licence d'une grosse entreprise francaise).

Prenons donc point par point ce qui pourrait etre le fer de lance de l'informaticien (industrialisateur ou développeur) :

L'application sur laquelle il travaille doit fonctionner.

C'est la base. Si elle ne fonctionne pas, l'utilisateur ne sera pas content, et comment être fier d'un résultat médiocre ? Ici, l'application est une application tiers, ce qui veut dire que je n'en maitrise pas du tout le fonctionnement. Je ne suis là que pour tenter de la garder dans les rails. Autrement dit, je dois palier les déficiences d'un autre. Il est très difficile de maintenir une application dont les erreurs peuvent arriver aléatoirement, pour des raisons aussi diverses que variées (panne réseau, base indisponible, bug applicatif...). Un exemple concret : que penser d'un démon (sensé tourner en tache de fond donc), qu'il faut régulièrement relancer. Pire : il est techniquement impossible de prévoir l'impact d'un arrêt brutal.

Il doit voir le travail fini (récompense subjective du travail accompli)

L'application doit produire une richesse. Cette richesse est en soi une récompense toute personnelle pour l'informaticien, qui peut estimer alors qu'il a bien accompli sa tache. Ici, j'industrialise une application X. Je ne sais absolument pas à quoi sert X, ce que ça fait, qui l'utilise, et pourquoi. X doit tourner, point. A quoi ressemble X ? Aucune idée. Je travaille également sur une application Y. Qui crée des images. Je ne peux pas les voir, les importer, les exporter. Je ne constate pas le travail accompli grace à moi (entre autres bien sur). Comment être fier de son travail si l'on est incapable de savoir à quoi il a servi ?

L'informatique ici est considérée comme un travail de l'ombre.

Il doit etre dynamique, changeant, et utile.

Dès lors qu'on trouve son emploi inutile à la cause, alors on perd tout intérêt à accomplir sa tache. A quoi sert mon poste ? Sur le diagramme des personnes impliquées sur le projet, je suis sensé être le point central, par qui toutes les informations passent. C'est un schéma malheureusement faux sur bien des points.
L'organisation globale des processus a été mal pensée et entraine des emplois inutiles. Là où une tache x pourrait être automatisée, on va employer une personne qui n'aura meme pas le temps de l'automatiser (si encore il en avait le droit), mais qui devra l'accomplir. On y bride l'innovation par la saturation des emplois du temps et des taches inutiles et/ou mal pensées. La moitié des personnes impliquées sur le projet ne devraient pas etre à leur poste mais travailler à l'amélioration du projet, au lieu de travailler à son maintien !

En partant du travail, l'informaticien doit tous les soirs pouvoir se dire qu'il a avancé.

C'est très bête et primaire à dire. Passer 3 jours à ne rien faire d'autre que programmer (sur un temps qui est en dehors des temps alloués aux projets, puisque, réduction des couts oblige, il faut estimer un projet à son temps réel divisé par 3) des opérations à faire le week-end qui suit ne motive pas : le temps passé sur place aurait pu remplacer le temps qui sera à passer le week-end.

L'organisation ne doit pas empecher le déroulement des opérations.

Comme dit sur le point sur mon premier travail, sans organisation, point de salut. Ici, tout est minuté (on compte les journées par dixièmes de journée, et on minute notre emploi du temps, meme si de toute façon on excède le temps imparti). Ce qui n'est pas nécessairement un mal, mais qui donne à penser que les choses avancent "parce que" le temps est minuté. Ce qui est faux en général.
Ensuite, tout est documenté, ce qui est formidable. Tout ? Non, une poignée d'irreductibles reste toujours sans documentation. Le plus curieux : ça ne dérange personne. De toute façon, ce qui est normalisé et documenté est fait pour etre outre-passé. Une modification est souvent faite *avant* sa demande. Cette meme demande, qui la rendra officielle et permettra à 2 personnes de travailler sur la demande alors que la modification a déjà été mise et est déjà utilisée massivement, plus la personne qui a modifié, qui va devoir faire la demande, et préparer les fichiers qui remplaceront la modification par... elle-meme. On nage en plein délire.
L'organisation ici entraine la désorganisation, ou l'exces d'organisation.

Le nerf de l'informatique devrait etre le mouvement pour le perfectionnement, l'innovation, et l'amélioration des conditions de vie et de travail.

Est-ce qu'on peut etre fier d'un travail pour lequel on passe plus de temps à lutter contre la passivité, sans succès ?