Gérer des projets informatiques ? C'est si divertissant !

La nuit, il faut dormir.

2010-06-01T17:27:00.000+02:00

Soirée « correction de bugs ». Nous sommes quatre développeurs à rester ce soir. Le chargé de projet technique^[1] est là lui aussi, ainsi que le chef de projet. Notre problème, c’est que divers comportements de l’application ne sont pas corrects : toutes les actions de l’utilisateur ne semblent pas prises en compte, ou pas correctement, si bien que l’état de l’application est incohérent^[2]. Il arrive également que l’application plante : une fenêtre d’erreur Windows indique un problème de gestion mémoire^[3], puis une fois sur deux, le PC reboote^[4] de lui même.

D’après le rapport de l’équipe de test, le problème de comportement est reproductible sur tous les postes utilisés. Le problème de gestion mémoire, par contre, n’en concerne que deux sur les sept que cette équipe possède.

20h. Après un petit break d’une heure avec la journée « régulière », nous faisons le point. Le problème de gestion mémoire semble lié au matériel. Le problème de comportement, lui, semble plutôt résulter d’une erreur de conception ou de programmation : l’application ne plante pas, c’est sa logique de comportement qui est en cause. A moins que les deux choses soient liées, mais si on ne peut pas l’exclure, on ne peut pas non plus partir de ce postulat pour le moment.

Le chargé de projet technique nous distribue donc les tâches comme suit :

Un développeur, que l’on appellera D1 par la suite, se chargera de vérifier les entrées utilisateurs, c'est-à-dire la bonne prise en compte de ses interactions avec l’application.
Un développeur, D2, se chargera de vérifier les sorties, c'est-à-dire la conformité du comportement de l’application avec la réponse aux entrées générée par cette dernière.
D3 se chargera de vérifier ce qu’il y a entre les deux, c’est à dire la génération de la réponse applicative aux entrées utilisateurs et qui servira de base aux sorties.
D4, enfin, tentera de reproduire le problème de gestion mémoire remonté par les testeurs, en utilisant l’une des deux machines concernées. Il installera préalablement son environnement de développement sur cette machine. De cette façon, une fois l’anomalie reproduite, il pourra exécuter ligne à ligne le code source^[5] concerné et pourra analyser le contenu de la mémoire au moment du problème.
Le chargé technique (CT), enfin, coordonnera les opérations et prêtera assistance aux quatre développeurs, sur demande.

Et moi, je suis D3.

21h. Je suis en train de rédiger différents scénarios de test permettant de valider ou d’invalider le comportement du générateur de réponses applicatives. D1 et D2 sont peu ou prou occupés à faire de même. D4, aidé de CT, sont en train de terminer l’installation de l’environnement de développement sur la machine des testeurs. Le chef de projet, quant à lui, est occupé dans son bureau. Nous savons qu’il aurait pu ne pas rester ce soir, mais qu’il le fait par soutien à son équipe. Nous l’en remercions intérieurement.

22h. D1 a repéré un problème mineur, mais qui ne peut expliquer le problème remonté. Il le corrige. D2 cherche toujours, en reproduisant ses scénarios de test. J’ai un doute, pour ma part : un comportement non spécifié, mais non proscrit par la spécification. Un « vide fonctionnel », en quelque sorte… J’en parle à CT qui se trouve aussi perplexe que moi. Nous tâchons de déterminer les conséquences de ce comportement, afin d’en estimer la capacité de nuisance mais aussi afin de s’assurer que le comportement fautif remonté par les testeurs ne soit pas parmi ces conséquences. D4 tente, en vain, de reproduire le problème de gestion mémoire.

23h. D1 a « refactoré »^[6], une partie du module de gestion des entrées. Cela signifie qu’il a réécrit une partie de ce code afin de le simplifier sans que cela ne modifie son comportement. On considère en effet qu’à comportement égal, un code complexe tend à provoquer plus d’anomalie qu’un code simple car il est sujet à plus de cas particuliers, et plus difficiles à déceler. D2 a également trouvé quelque chose dans les sorties. Rien qui puisse tout expliquer, mais une anomalie se produisant dans certains cas particuliers et qu’il commence à corriger. CT et moi travaillons toujours à déterminer les implications du comportement non spécifié observé une heure plus tôt. D4 n’a toujours pas reproduit le problème et commence à désepérer.

23h30, petite pause décidée à l’unanimité. Nous allons fumer ~~une~~ deux cigarettes, baillons copieusement, puis faisons un point :

D1 nous explique son refactoring des entrées. Pas de commentaires, mais une approbation générale. Il en a encore pour une bonne heure, d’autres points mineurs ayant été identifiés.
D2 nous explique plus en détails l’anomalie trouvée dans les sorties. Celle-ci ne se produit que lorsque la réponse applicative servant de base aux sorties est dans un certain état.
- J’objecte : la réponse applicative ne peut pas contenir les valeurs provoquant cet état. Si le cas se produit, c’est la réponse applicative elle-même qui est fautive.
- D2 : « Ah ok, je ne pensais pas. Mais à supposer qu’elle le soit, il vaut mieux que la sortie ne plante pas ! »
- CT : « Oui, c’est clair. Autant blinder^[7], d’autant que t’as déjà commencé le refactoring il me semble. »
- D2 : « Oui, j’ai presque fini en fait. »
- D3 (moi) : « Tu pourras me donner des infos pour reproduire le cas que tu as observé ? Il faut que je corrige le générateur ».
- D2 : « Ok, je te montre ça tout à l’heure. »
CT et moi décidons de réécrire la partie de code engendrant le comportement non spécifié décelé une heure et demi plus tôt afin d’éviter qu’il se produise. Nous soupçonnons ce comportement ambigu de générer des incohérences qui pourraient expliquer le problème de gestion mémoire sur lequel travaille D4, voire celui que rencontre D2.
D4 est fatigué de tester, tester, et tester encore sans parvenir à reproduire le problème mémoire remonté par les testeurs. Nous nous demandons si l’installation de l’environnement de développement sur la machine des testeurs ne prévient pas la reproduction de l’anomalie du fait de la modification de la représentation mémoire qu’elle engendre.

Minuit. C’est déjà demain. Nous nous y remettons.

1h30. D1 a terminé sa partie. Ses tests passent, tout va bien. La source des problèmes remontés n’était donc pas dans les entrées, tandis que des problèmes potentiels ont été fixés. Il rentre chez lui. Nous l’envions un peu, sauf D2 qui ne semble même pas s’être aperçu de son départ.

2h. D2 est en train de finaliser son refactoring. Il devrait en avoir terminé dans une demi-heure, ce après quoi il pourra me montrer le cas particulier dont on a parlé lors du point de 23h30. De mon côté, je viens de terminer réécriture de la partie du générateur qui provoque le comportement non spécifié : il ne se produit plus. Mais je n’ai toujours pas trouvé l’origine du comportement fautif remonté par les testeurs. D4 continue de tester en vain, mais nous annonce qu’il va bientôt abandonner.

2h15. Cri de joie de D4 : « Je l’ai ! La mémoire ne peut être ‘written’ ! ».

2h15’30’’. Cri de colère de D4. Son PC vient de rebooter. Le problème est reproduit, mais hélas dans sa version la plus radicale. « Et m****, c’est quoi ce ****** ? J’ai rien fait de spécial, j’ai rien eu le temps de noter, comment je vais le reproduire maintenant ? Je vais pas y repasser 3 heures ». En fait, non, cela en a plutôt pris six.

2h45. D2 m’explique rapidement le cas particulier évoqué plus tôt et qui fait planter la sortie. Il m’indique les valeurs d’entrée qu’il utilise pour le générer. Je les note pour tout à l’heure et lui demande s’il se prépare à rentrer. « Non, j’ai découvert un souci sur mon refactoring de tout à l’heure, il faut que je le corrige d’abord ». CT va lui prêter main forte.

3h. Je parviens à reproduire une génération de réponse applicative qui correspond au cas erroné remonté par les testeurs. Et ce malgré mon refactoring, donc. Les valeurs d’entrées ne correspondent pas à celles remontées par D2. Par contre, que se passe-t-il si j’essaie le cas de D2 ? Ai-je le même comportement ?

3h30. « P*****, je l’ai ! ». C’est D4 qui est parvenu à reproduire le problème, mais sans rebooter cette fois. Il note scrupuleusement l’état de sa mémoire à ce moment précis, ainsi que les paramètres utilisés.

4h. Le cas que m’a remonté D2 est différent de celui des testeurs. J’ai rapidement patché celui des testeurs par mise en place de blindages divers, c’était le plus simple à moins de tout refaire. En termes de programmation, ce n’est pas très beau, mais ça résous le problème. Par contre, le cas de D2 est plus complexe. J’ai de la ré-écriture à faire.

4h05. CT nous demande de terminer ce que l’on fait et de ne rien commencer d’autre. Il est temps d’aller se coucher. « Ok. J’ai presque fini ». Je ne sais plus trop, c’est peut-être moi qui ai dit ça.

4h30. Je m’emmêle les pinceaux dans mon code, et m’y reprends à plusieurs fois pour faire des choses pourtant simple. Je râle dans mon coin. D2 trace, trace et re-trace^[8] son code, aidé par CT, son problème de refactoring n’étant pas réglé. D4, quant à lui, « blinde », à défaut de pouvoir régler la cause du problème. « J’y comprends rien, là. Ce cas là ne peut pas se produire, en théorie. Ecoute, je blinde en attendant de voir ça à tête reposée », explique-t-il à CT.

5h. CT : « Vous y êtes ?
- Oui oui, presque, deux secondes. », lui répond D4.

5h15. J’ai terminé. Fixer le cas soulevé par D2 a été difficile car impossible à reprendre sans modifier la conception, mais ça va, ce n’est pas trop mal fait au final. Je dis au revoir aux autres et je rentre.

Le lendemain, je me réveille vers 10h00. J’arrive au travail vers 11h00. CT est déjà là, ainsi que D1 et D4. J’ai un peu honte. « Vous êtes rentrés à quelle heure ?
- le temps de rentrer, vers 7h… On est parti vers 6h et demi, m’explique D4.

Plus tard, dans la journée, j’apprends que le cas soulevé par D2 et que j’ai fixé ne pouvait pas se produire : les entrées ne pouvaient fournir de telles valeurs. Comme D1 était déjà parti, nous ne nous en sommes pas aperçus et avons fait tout cela pour rien.

Le lendemain, nous apprenons par CT que le problème mémoire se produit toujours. D4 a bien fixé le problème, mais du fait de la fatigue, il n’a pas effectué de commit CVS^[9], si bien que son correctif est resté sur son poste. Entre temps, les testeurs ont désinstallé l’environnement de dev de leur machine, si bien que tout son travail de cette nuit là a été perdu.

Quelques jours plus tard, les testeurs nous remontent de nouvelles anomalies. Plusieurs d’entre elles proviennent des refactorings effectués cette nuit là par D1, D2 et moi : des erreurs de programmation manifestement dues à l’inattention et la fatigue, mais aussi des erreurs de logique et d’appréciation de conséquences dues à la précipitation dans laquelle ces modifications ont été faites. Certaines corrections ont demandé plusieurs jours de travail. L’une d’entre elle a été corrigée par l’annulation du refactoring effectué et son remplacement par une version précédente contenue dans CVS.

Moralité : travailler « à l’arrache », de nuit, pour fixer des bugs ou terminer des travaux dans l’urgence, ça ne sert à rien d’autre que se donner bonne conscience. C’est même contre-productif, le nombre de problème générés pouvant dépasser le nombre de problèmes réglés. En outre, cela déstabilise l’équipe de développement, du fait de la fatigue et du décalage horaire engendrés.

Il s’agit donc d’une pratique à bannir.

Note : Cette histoire est basée sur des faits tout à fait réels, et n’a vraiment rien d’extraordinaire. J'ai du la vivre au moins dix ou quinze fois. Nombre de développeurs de votre entourage peuvent certainement vous raconter des histoires très similaires.

Notes
[1]Cette structure de projet comprenait une branche développement, dite « technique », et une branche IHM, composée de designers et de graphistes.
[2]Ce que l’on appelle ici « l’état de l’application », c’est la représentation mémoire que celle-ci à de l’utilisateur, de ses actions, et des réponses qu’elle génère en réaction à ces dernières.
[3]En presque-français dans le texte, la boîte indique « AppName.exe - Erreur d'application. L'instruction à "0x77F738a9" emploie l'adresse mémoire "0X0259200a". La mémoire ne peut pas être 'written' ». On aurait bien aimé qu’elle le puisse, pourtant…
[4]Nous sommes sous Windows 98 au moment où ceci se déroule. Aujourd’hui nous aurions un simple message d’erreur. Au pire un écran bleu, mais il faudrait se battre pour arriver à l’obtenir.
[5]Ce que l’on appelle code source, c’est l’ensemble des instructions qui constituent le programme, en langage compréhensible par le programmeur (ici, ce langage se nomme « C++ »). Le code exécutable, quant à lui, est une traduction de ce code source en langage compréhensible par la machine (et que l’on appelle parfois « langage machine »). L’application telle qu’installée et distribuée aux utilisateurs ne contient que le code exécutable. Faire le lien entre ce code et le code source nécessite une autre application, que l’on appelle ici « environnement de développement ».
[6]Et pardon pour ce barbarisme.
[7]« Blinder », en jargon, signifie prévoir que des cas aberrants puissent se produire pour les gérer de façon cohérente. Par exemple, si une probabilité se trouve à 1.5 tandis qu’elle ne peut normalement qu’être comprise entre 0 et 1, l’application la ramène à 1 avant de l’introduire dans ses calculs.
[8]« Tracer », c’est exécuter son programme non pas en le lançant normalement, mais manuellement, instruction par instruction. Ceci permet d’observer l’action exacte de chaque instruction, afin de solutionner un problème.
[9]CVS est un outil de gestion du code source. Le « commit » consiste à intégrer les modifications effectuées sur un poste de travail à la base de code source commune à tous les développeurs. C’est cette dernière qui est utilisée pour construire et livrer les versions de l’application. En l’absence de commit, la modification n’est visible que sur le poste de travail sur laquelle elle a été faite.

A quoi répondent les méthodes agiles ?

2010-05-08T15:51:00.002+02:00

« RAD », puis « eXtreme programming », puis « Scrum »… On parle beaucoup des méthodes de développement logiciel dites « agiles » depuis les années 1995/2000. Ces méthodes se posent en réponse aux problèmes de rigidité rencontrés avec les méthodes traditionnelles de type « analyse-spécification-conception-programmation-tests-recette » - le fameux « Cycle en V ».

La méthode traditionnelle, c’est en quelque sorte le modèle de développement de l’Airbus A-400-M, où la programmation est remplacée par la construction et l’assemblage. L’actualité qui a entouré le développement de cet appareil eut été tout à fait applicable à un projet informatique : on présuppose que tous les tenants et aboutissants du projet sont maîtrisés dès son début, que ceux-ci sont invariants, et que les oublis, incohérences, et mauvaises surprises n’existent pas. Pourtant ils existent, et ils posent de nombreux problèmes techniques, économiques, mais aussi humains.

Ainsi - et ce n’est qu’un exemple - découvrir une ambigüité de spécification ou de conception alors que le projet entre en phase de programmation implique de « revenir à la planche à dessin ». Ceci est lourd de conséquences : le coût final et le délai de livraison s’en trouvent modifiés, et la responsabilité des intervenants est engagée^[1]. S’il s’agit d’un projet spécifié par un client pour être réalisé par son prestataire, cela est d’autant plus impliquant : les pénalités, les délais de paiement ou les coûts engendrés peuvent compromettre le projet, mais aussi la survie du client ou du prestataire informatique. Ce risque pousse chaque acteur à « blinder » sa partie de façon à pouvoir exiger de l’autre le paiement des surcoûts en cas de mauvaise surprise : « C’est une incohérence de notre spécification, dites-vous ? Mais enfin, VOUS l’avez validée en tant que sachant. ». Ceci à un coût, prend du temps, est générateur de conflits et de blocages, alors que l’issue des conflits est souvent incertaine.

Les méthodes agiles ont donc intégré la notion de changement comme réponse à ces problèmes. Elles définissent des méthodes permettant de modifier la définition du produit en cours de développement sans pour autant revenir à la case départ. Pour ce faire, elles font intervenir le client à tous les stades du développement et non plus aux seules phases de spécification fonctionnelles et de recette et acceptation du produit fini (il existe dans le cycle en V un comité de pilotage régulier et qui implique le client, mais s’il a la possibilité de mesurer les écarts entre l’avancement réel et l’avancement prévu, il n’a pas réellement les moyens d’y remédier). Ceci est rendu possible par le raccourcissement du cycle de développement : schématiquement, un même produit, s’il est développé en un unique cycle en V d’une année, sera développé en 10 à 30 cycles Scrum ou eXtreme Programming. Ceci donne autant d’occasions aux équipes techniques et fonctionnelles de se réunir autour du produit en construction et de détecter une incohérence de spécification, un oubli, une infaisabilité technique, ou simplement de constater une évolution du besoin client, pour faire évoluer la définition du produit en conséquence.

Outre cela, certaines méthodes agiles telles eXtreme Programming définissent des pratiques techniques destinées à améliorer la maintenabilité du produit (qu’il s’agisse de maintenance corrective ou évolutive) ainsi que sa robustesse. D’autres, au contraire, laissent les pratiques techniques au libre choix de l’équipe de développement, pour ne s’intéresser qu’au suivi opérationnel du projet - c’est le cas de Scrum.

Attention cependant, car si la théorie de ces méthodes agiles est attrayante, leur pratique révèle quelques défauts et difficultés de mise en place :
- le client peut se montrer résistant au changement de mode de fonctionnement impliqué par la méthode (sans aucun jugement sur la raison de cette résistance)
- la spécification fonctionnelle telle que définie par le Cycle en V peut avoir valeur contractuelle, et donc demeurer nécessaire
- certains éléments des méthodes agiles peuvent s’avérer difficile à mettre en place car coûteux (programmation en binôme définie par eXtreme Programming), trop idéalistes (estimation des tâches Scrum faite par toute l’équipe et non par son responsable, ce qui suppose que chacun sait estimer la durée d’une tâche), ou simplement agaçants (« planning poker » : le client n’est pas là pour jouer et préférerait parfois entendre « réunion de définition de cycle de développement » - c’est que ça compte la communication !)

Appliquer une méthode « telle qu’écrite dans le livre » n’est donc pas forcément la meilleure solution^[2]. Par contre, se l’approprier et l’adapter à ses besoins et contraintes peut donner d’excellents résultats : meilleure adaptation du produit aux besoins du client, rapport client/fournisseur facilité par l’acceptation du changement^[1], et dans les meilleurs cas, réduction des coûts et délais. C’est précisément l’esprit de ces méthodes : rester proche des réalités et de la pratique, plutôt que de s’enfermer dans un raisonnement rigide car uniquement théorique.

Notes
[1]Ce précédent billet sur la gestion des changements d'avis du client en parle plus largement.
[2]D'où ce précédent billet sur l'application des méthodes agiles.

Symantec AntiVirus Corporate Edition v7.5: régime pour un dévoreur d'espace disque.

2010-04-25T13:08:00.002+02:00

Enfin ! Mon problème de disque dur est réglé.

Depuis quelques temps, Windows XP se plaignait régulièrement du manque d'espace sur mon disque C. Désinstallation des logiciels et composants inutiles^[1], nettoyages à grand renfort de CCleaner ^[2] m'avaient alors permis de récupérer un bon Go. « Ça devrait aller », m'étais-je dit.

Et pourtant, non, ça n'allait toujours pas. J'ai injustement accusé divers composants, dont le système lui même, j'ai compressé certains répertoires, mais tous les deux ou trois jours, l'espace que je grapillais se trouvait immanquablement dévoré. Il y avait quelque chose d'autre.

L'idée de simplement remplacer mon disque dur par un modèle plus grand ne me satisfaisait pas. En toute logique, cela ne devrait faire que repousser le problème, simple question de temps. J'ai donc creusé, en inspectant la taille des différents répertoires de C, pour m'apercevoir que celui-ci, sous-répertoires compris, occupait 50% de l'espace du disque :

C:\WINDOWS\Profiles\All Users\Application Data\Symantec\Symantec AntiVirus Corporate Edition\7.5

Il s'agit du répertoire de travail du client Symantec AntiVirus Corporate Edition v7.5 installé sur ma machine^[3]. A la racine de cette arborescence, des fichiers (.wdb, .iad, .iex, et .vdb) qui semblent être des mises à jour de définitions de virus. Deux sous répertoires suspect également : I2_LDVP.VDB\ et I2_LDVP.TMP\

A partir de là, c'est allé très vite : une recherche sur Google m'a mené à cette page du forum support de Symantec, sur laquelle un Trusted Advisor^[4] explique que les fichiers peuvent être effacés sans risque, et que le sous-répertoire I2_LDVP.VDB\ peut être vidé sans danger.

Quelques hésitation tout de même avant de procéder. Mais au pire, j'étais bon pour une réinstallation du client de mon poste, le risque pouvait donc être pris.

Une fois l'opération effectuée, il y a une petite heure, mon disque C n'était plus occupé qu'à 60%. J'ai alors pu observer que le client Symantec récupère par téléchargement les fichiers de travail dont il a besoin. Ceci représente un volume modeste, et explique que l'effacement effectué ne l'empêche pas de travailler et ne génère pas de risque. Par contre, les définitions obsolètes, au lieu d'être effacées, sont laissées à l'abandon dans le répertoire de travail. Au fil des mois, cela représente un volume conséquent, et c'est pourquoi le support de Symantec conseille de les supprimer.

On peut juste regretter que ce ne soit pas automatique, ou mieux documenté !

Notes
[1]Dont les anciennes versions du runtime Java 5 et 6. Chaque mise à jour, même mineure, consiste en l'installation d'un runtime complet, soit une centaine de Mo, les versions antérieures devant être désinstallées manuellement. J'avais ainsi quatre ou cinq versions de Java 6.
[2]Je recommande vivement cet outil. Nettoyage du cache d'Internet Explorer, de Mozilla, de Chrome, nettoyage des programmes de désinstallations des patchs Windows (encombrants et pas destinés à servir), tout y passe...
[3]Cet anti-virus pour entrepris se déploie sur tous les postes de son réseau, mais s'administre de façon centrale depuis le poste de son administrateur.
[4]Il s'agit d'un membre du forum que Symantec reconnait capable de renseigner les utilisateurs. C'est donc une source fiable d'après l'éditeur du produit.

Méthodes agiles... pour la gloire ou pour atteindre l'objectif ?

2010-04-22T00:07:00.000+02:00

2000 : « Ah non, ce n'est pas ce que dit la Méthode ! Tu ne peux pas dire que tu fais du XP si tes programmeurs ne travaillent pas tous et tout le temps en Pair Programming ! Normalement, ce sont les 12 pratiques de base qu'il faut appliquer. »

2010 : « Ah non, ce n'est pas ce que dit la Méthode ! Tu ne peux pas dire que tu fais du Scrum si vous n'êtes que deux à évaluer la charge de travail. Normalement c'est toute l'équipe qui doit le faire. »

Fichus normopathes... Vous avez peut-être déjà entendu des choses comme celles-ci, vous aussi ? Eh bien qu'à cela ne tienne. Mes équipes et moi-même ne « faisions donc pas du XP » à partir de 1999, comme nous ne « faisons pas du Scrum » depuis 2006 ou 2007. Nous ne faisons toujours pas du XP, bien que nous continuons à appliquer ses pratiques de bases qui nous conviennent le mieux^[1]. A vrai dire, c'est même mieux ainsi : ne pas prétendre utiliser ces méthodes nous met à l'abri de ceux qui se font un devoir moral de les représenter mais sans nécessairement en avoir bien compris l'intérêt.

C'est qu'une méthode, qu'elle soit agile ou non, ce n'est qu'un outil. Rien de péjoratif dans cette négation ; simplement, un outil n'a pour seule fin que de faciliter l'atteinte d'un objectif. Qu'importe alors que l'on exploite toutes ses possibilités ou non, du moment que l'on exploite celles qui facilitent l'atteinte de l'objectif.

Utilisez vous toutes les fonction de votre électroménager simplement « parce qu'il le peut » et que toutes ces fonctions sont destinées à vous faciliter la vie ? J'en doute, et parierais plutôt que vous utilisez les fonctions qui vous facilitent effectivement la vie.

Un argument fréquent des défenseurs de la méthode « by the book » est que la méthode est un tout. Que ne l'appliquer que partiellement lui fait perdre sa cohérence et son intérêt. Pourtant, deux réponses s'opposent à cet argument :

Réponse empirique : lorsque l'expérience montre que ce n'est pas le cas, la question ne se pose même pas. Si appliquer la partie de la méthode qui vous semble appropriée donne des résultats positifs, on ne peut pas dire que c'est sans intérêt ou incohérent.

Réponse théorique - elle fait partie intégrante de la méthode : l'adaptation est le troisième pilier de Scrum tandis que le slogan d'XP était "Embrace change!". Le tout est d'utiliser la méthode de façon cohérente. Les méthodes agiles sont conçues dans un esprit d'adaptation au besoin, c'est même leur raison d'être. Elles sont conçues pour être adaptées, non pour être appliquées de façon stricte et sans discernement.

Ainsi, serait-il cohérent de s'astreindre à appliquer la pair programming dans un contexte où l'on constate que le surcoût engendré n'est pas compensé par l'économie réalisée en maintenance corrective ? Serait-il intéressant de demander à chaque membre de l'équipe de donner son estimation de chaque fiche du backlog alors qu'en fin de sprint il ne reste généralement pas de travail non réalisé tandis que l'estimation n'est faite que par une ou deux personnes ? Si le contexte - en l'occurrence, le fait que ces deux personnes soient douées pour l'estimation de charge et fassent partie de l'équipe - le permet, pourquoi l'ignorer ? Et si le contexte change, il est toujours possible de s'y adapter, en ré-instituant la pratique définie par la méthode.

Tout est donc une question de contexte et d'adaptation.

Afin de sélectionner les éléments pertinents d'une méthode agile ou d'en optimiser l'emploi, je vois deux façons de faire, mais il en existe certainement d'autres:

Ajouts successifs, au fil des itérations : Au début, on n'utilise pratiquement rien de la méthode. Au fil des itérations, on en teste de nouveaux éléments - par exemple, l'estimation du backlog par toute l'équipe et non par une seule personne. On compare avec les itérations précédentes, toute l'équipe étant impliquée dans cette discussion et libre de ses propos : A-t-on gagné du temps ? Evité des erreurs courantes ? Gagné en partage de connaissances ? Gagné en qualité ? En confort ? Ou quoique ce soit d'autre ? On ne continue d'utiliser que les éléments qui se révèlent effectivement utiles.

Soit par suppression des éléments inutiles : on commence par appliquer la méthode « by the book », ou du moins autant que possible, puis on supprime au fil des itérations les éléments qui se révèlent inutiles ou encombrants. Cette sélection se fait elle aussi par la discussion.

On peut ainsi s'approprier la méthode au rythme de l'équipe, sans mettre les projets en péril, et sans les ralentir. Au bout de quelques semaines, on arrive à une première ébauche valable. Au bout de quelques mois, la méthode est rodée et devient naturelle. On peut alors penser à l'améliorer, ou simplement à l'entretenir, en en remettant certains points en question de temps en temps, toujours grâce à la discussion.

Mais l'outil n'est pas une fin en soi, tandis qu'XP ou Scrum ne sont pas des clubs. Il n'y a pas d'intérêt ni de gloire à rendre l'outil prioritaire sur l'objectif de façon à faire partie de ceux « qui font du Scrum » ou du XP, comme on l'entend trop souvent. Adapter une méthode agile à son contexte d'utilisation, c'est précisément aller dans le sens de la méthode. Cela demande un peu de rigueur, un peu de remise en question, un peu de confiance, mais cela paie au final bien plus que toute application dogmatique. Vous ne trouvez pas ?

Notes
[1]Et qui n'ont rien d'incompatible avec Scrum puisque celle-ci s'abstient de définir les pratiques techniques à suivre pour ne s'intéresser qu'au cadre dans lequel on les applique.

La qualité, c'est le sourire du client...

2010-03-18T19:09:00.001+01:00

« ... et c'est sa seule définition. En faire plus que cela, ou ajouter des choses pour faire plaisir, c'est de la surqualité. Ça n'a pas d'intérêt, et ce doit être évité. »

C'est ainsi que les choses m'ont été présentées au cours d'une réunion avec ma direction technique, chez un ancien employeur.

Comment dire... Oui, mais non. En fait, ma direction technique confondait qualité et complexité du produit. Or si conserver le produit aussi peu complexe que possible est effectivement une bonne conduite à tenir, s'en tenir à l'appréciation du client pour définir la qualité du produit est une erreur assez lourde.

Pourquoi éviter les ajouts ? Pour des raisons de complexité fonctionnelle et technique, et pour des raisons contractuelles.

Il est clair qu'il faut éviter de réaliser pour des clients des fonctions non inscrites dans la spécification fonctionnelle du produit commandé. On peut parfois être tenté de le faire, en guise de cadeau ou de "geste"^[1], mais c'est une erreur.

Pourquoi ? Simplement car si ces fonctions ne sont pas définies formellement, elles n'en sont pas moins partie intégrante du produit livré une fois qu'elles ont été développées. Elles sont de ce fait couvertes par la garantie, et en cas de dysfonctionnement, c'est la responsabilité de l'entreprise que de les corriger. Cela coûte du temps, et est rendu d'autant plus difficile que l'absence de spécification rend floue la notion de bon fonctionnement. On parle donc de temps développeur, de temps de gestion de projet, et aussi de temps commercial dans les cas les moins favorables.

Outre cela, de telles fonctions, même anodines en apparence, peuvent poser de nombreux problèmes. Problèmes techniques du fait des conséquences de ces ajouts lors des évolutions futures, mais aussi problèmes fonctionnels. Je pense ainsi à un "mode prévisualisation" qui avait ainsi été réalisé sur un projet de back office d'intranet :

La spécification décrivait qu'une fois rempli un formulaire de saisie de contenu de type "articles" par l'utilisateur, celui-ci pouvait au choix abandonner ou valider son entrée. L'abandon le conduisait à l'étape précédente (la liste des "articles" et des actions associées, en l'occurrence), la validation le conduisait à la page de contenu en question, telle que publiée.

Une fonction non spécifiée avait été ajoutée à ce système : la prévisualisation. Elle était assez analogue à ce que l'on peut trouver sur les plateformes de blogs pour les billets et commentaires. Simple à réaliser, il ne nous avait coûté que quelques heures sur un projet de centaines de jours. Le client était ravi car il désirait cette fonction mais sans que celle-ci n'ait été spécifiée et intégrée au budget. Nous étions ravi également car à peu de frais nous avions renforcé la relation avec ce client que nous aimions bien du fait de sa récurrence et de ses qualités humaines trop rares dans le monde du service informatique...

Malheureusement, ce mode prévisualisation s'est révélé problématique lorsqu'il s'est agit de faire évoluer l'application. En effet, lors de la définition de la version suivante, il était maintenant entendu par le client que cette fonction devrait être applicable à tous les formulaires de saisie de contenus, et pas seulement aux articles. L'argument était que par spécification la gestion des formulaires de contenu obéissait aux mêmes règles quelque soit le type de contenu, et que par conséquent, cette fonction disponible pour les seuls "articles" aurait également due être applicable aux "offres d'emplois" et "annonces diverses". Le comportement de la version courante, en production, a dès lors été considéré par le client comme un dysfonctionnement ayant échappé à la recette. Royalement, le client nous a même indiqué que la mise en production valant recette il ne demandait pas réparation de ce manquement à la version courante, mais seulement à la version suivante.

L'interlocuteur client ayant changé^[2], il n'était pas possible de le prendre à témoin. Le flou généré par l'ajout de cette fonction non documentée avait donc profité au client, notre service commercial n'ayant - à juste titre à mon sens - pas souhaité contre-argumenter tandis que nous n'étions pas en position de force et que le coût engendré était supportable.

C'est pour éviter ce type d'embêtements qu'on dit toujours de ne jamais faire de cadeaux aux clients et de s'en tenir « à la spécification, rien qu'à la spécification, et à toute la spécification » (dites "je le jure")... Et en cela, oui, les propos de ma direction technique lors de la réunion évoquée au début de ce billet étaient fondés.

Pourquoi l'appréciation du produit par le client ne suffit-elle pas à évaluer la qualité du produit ? Parce que c'est nous qui le maintenons.

L'appréciation du produit par le client est basé sur différentes choses:

les fonctions proposées et leur facilité d'emploi: bien que définies par le client, celui-ci les redécouvre lors de la livraison. Ses idées ont pris forme, pour ne pas dire vie, et c'est cette mise en situation réelle qu'il apprécie.^[3].
les performances: plus c'est rapide plus c'est apprécié, surtout si l'on parle de systèmes interactifs.
la robustesse: plus il observe de dysfonctionnement, moins le client apprécie le produit.
le look: plus important que l'on pourrait le croire, le look de l'interface graphique permet de faire passer bien des choses... comme il peut au contraire ruiner l'appréciation d'un excellent produit.
mais aussi, la relation qu'il a avec le fournisseur: un bon relationnel aide considérablement à faire accepter au client un produit imparfait. Au contraire, un mauvais relationnel lui fera rejeter un produit remplissant pourtant tous ses critères techniques d'appréciation.

Et c'est tout.

Le client ne prend pas en compte la maintenabilité du produit. Il ne prend pas non plus en compte sa portabilité, en cas de changement d'environnement. Il a raison, puisqu'il s'agit de choses purement techniques, transparentes pour lui, et qu'il n'est sauf exception pas en mesure d'évaluer.

Pourtant, ces paramètres doivent être pris en compte impérativement car ils conditionnent la faisabilité et le coût de toute modification future ou de tout changement de plateforme d'hébergement. Pour ne s'intéresser qu'à la maintenabilité, un produit mal ficelé, mal conçu, mal écrit, peut finalement tourner à force de correctifs, et ce au point de donner l'impression d'être "de bonne qualité". Mais alors, la moindre évolution ou correction devient un coûteux casse-tête. L'adhérence entre les différents modules constituant le produit est l'un problèmes de maintenabilité les plus courants. La propreté et la structure du code source en est un autre.^[4].

Je ne sais pas s'il est utile de donner un exemple ici, toute personne impliquée dans le processus de développement informatique ayant normalement déjà vu son lot de produits mal pensés ou mal construits.

Or présenter un devis prohibitif pour une modification bénigne n'est pas la meilleure façon d'être compétitif ni de travailller dans de bonnes conditions. Rater une date de livraison ou se voir refuser une recette pour cause d'anomalies nombreuses et sans solution non plus. Donc, si personne ne se préoccupe de la maintenabilité du produit, c'est à la MOE de le faire, ne serait-ce que pour se rendre service. Et si votre hiérarchie vous dit le contraire, vous pouvez toujours opiner du chef et acquiescer, mais gardez à l'esprit qu'elle a tort.

Sans aller jusqu'à suivre la norme ISO 9126 qui définit la qualité logicielle, ce qui serait dans la majorité des cas l'excès inverse de celui de mon ancienne direction technique, il est intéressant d'en avoir le sommaire à l'esprit et de s'en inspirer autant que raisonnablement possible. Rendez-vous service !

Ah... mon ancienne direction technique avait également ajouté « c'est ce que l'on apprend en école d'ingénieurs », à propos de sa définition de la qualité. J'ose croire qu'aucune école sérieuse n'oserait donner pareille leçon, mais je suis intéressé par vos témoignages !

Notes
[1]Parce que le client est un bon client, parce qu'on le connaît depuis longtemps après plusieurs projets conduits pour lui, parce que ce client là est courtois et que ce n'est pas le cas de tous, parce qu'il est organisé et ne vous impose pas de travailler dans l'urgence, parce qu'il est est de bonne foi, lui... bref, pour des tas de raisons.
[2]Inutile de préciser que nous y avons perdu au change, je suppose...
[3]Il est déjà arrivé qu'un client me dise "c'est génial ce que vous avez fait là" à propos d'une fonction qu'il avait lui-même défini. Lui rappeler que l'idée était de lui l'avait conduit à m'expliquer que c'était "génial de la voir en vrai" (sic).
[4]L'article "Plat de spaghetti" de Wikipédia illustre bien la chose.

Invité par le client ? Pas de panique !

2010-01-30T20:18:00.005+01:00

Vous avez un déplacement. Vous partez aujourd'hui, et atterrissez (normalement) à 18h35 à l'aéroport de Lantas-Tique, à 900 km de chez vous. Il est prévu que vous passiez la nuit à l'hôtel, pour passer la journée de demain au siège social de votre client, où il soumettra son projet à sa direction technique. Vous l'assisterez en qualité de maîtrise d'oeuvre : vous répondrez à toutes les questions de la direction technique, laquelle répondra de son côté à toutes vos questions concernant les contraintes à respecter. Vous repartirez demain soir à 19h50.

Votre client se déplace, lui aussi. Son bureau est dans votre région. Il n'y a pas grand chose à faire à Lantas, si bien qu'il vous propose de dîner ensemble ce soir, dans un petit restaurant sympathique qu'il connaît bien, à proximité de son hôtel et du vôtre. Ce type de dîner est un moment informel. S'il permet de se détendre et de renforcer le rapport de confiance avec votre client, il est également un moment d'exposition qu'il convient d'aborder avec une certaine prudence.

Pourquoi ? Parce que les événements informels, du fait de leur absence de cadre, sont le terrain privilégié des gaffes et des indiscrétions. Vous devez évidement ne pas en commettre, mais vous devez également recevoir celles commises par votre client avec prudence. Cependant, un peu de "off", parfois, permet de faciliter bien des choses et d'éviter des problèmes.

Les quelques règles qui suivent ne sont issues d'aucun livre. Elles sont issues de situations auxquelles des collègues ou moi-même avons été confrontés. Elles ne sont livrées ici que pour tenter de vous aider si vous ne savez trop comment vous y prendre ou que vous appréhendez ce huis-clos. Si vous êtes déjà rompu à la chose, ce qui suit ne vous intéresse probablement pas... mais en ce cas, et si vous voulez bien nous en faire part en commentaire de ce billet, votre propre retour d'expérience intéressera certainement quelques lecteurs, et m'intéressera de toutes façons.

S'adapter, tout en restant spontané

Votre client vous invite. C'est très sympathique, mais c'est aussi lui qui vous paie pour un travail pour lequel il vous a sollicité. Vous ne pouvez donc pas vous permettre de vous comporter comme si vous étiez à armes égales : si quelqu'un doit s'adapter... c'est vous.

Si vous le connaissez déjà bien, peut-être pouvez vous prendre certaines libertés^[1], mais nous nous trouvons dans ce cas hors du champ d'application de ce billet. Le reste du temps, c'est une loterie : si votre client est ouvert, agréable, sympathique, et de personnalité compatible avec la vôtre, c'est une chance. Sinon... tant pis, c'est le jeu. Quoiqu'il en soit, lors d'un moment de détente, rien de pire qu'un convive qui semble réfléchir à ses moindres faits et gestes, ou pire encore, qui semble se forcer. Le premier est terriblement ennuyeux, tandis que le second est franchement vexant.

En cas de décalage trop important - par exemple, votre client qui vous invite à danser sur les tables tandis que ce n'est pas trop votre truc^[2] - vous pouvez tout à fait refuser avec le sourire et expliquer que vous êtes plutôt du genre réservé pour votre part. Qu'importe qu'il vous considère comme "sympa mais pas drôle", cela ne peut pas vous nuire. Si vous le suivez, par contre, vous pourriez le regretter puisque vous ne l'assumeriez pas nécessairement. J'y reviendrai un peu plus loin.

Le décalage inverse est quant à lui bien plus facile à gérer. Prenez simplement garde à ne pas brusquer votre client qui manifestement est plus introverti, plus réservé, ou plus dans la retenue que vous.

En tous les cas, en cas de décalage insurmontable, tâchez de faire en sorte que cette soirée ne dure pas trop. Vous pouvez, poliment, en fin de repas, prétendre avoir à relire vos notes pour préparer le lendemain. Cela peut permettre de rompre un ennui gênant comme éviter de devoir supporter plus longtemps une incompatibilité de personnalités qui, si elle durait, pourrait conduire à l'agacement. Cela pourrait créer des difficultés par la suite.
Rester professionnel

Supposons maintenant que les choses se passent bien, que le relationnel est bon. Vous vivez certes un moment de détente, mais vous n'êtes pas des potes pour autant. Vous pourriez gêner votre convive en étant trop familier^[3], mais pas seulement : trop peu de distance pourrait vous mettre en difficulté par la suite, en cas de désaccord avec votre client dans le cadre de vos affaires avec lui. Votre ami d'aujourd'hui est peut-être votre accusateur de demain en cas de problème sur le projet.

N'oubliez pas non plus que sympathiser peut être un jeu professionnel pour votre client. Il peut s'agir d'une tactique de sa part pour vous avoir de son côté, ou vous demander des services que le contrat que vous avez passé avec lui ne lui permet pas de vous demander. Certaines personnes sont très douées à ce jeu là.

Quant à pratiquer vous même ce jeu, je ne peux le recommander. Tout se sait, et ceux qui jouent à ce jeu perdent au final toute crédibilité - clients comme prestataires. Il en résulte une méfiance non dite, une prise de précaution non affichée, qui finit toujours par nuire au joueur en question, parfois même sans qu'il le sache. C'est qu'au travail il n'y a aucune raison de ne pas être hypocrite avec une personne malhonnête.

Dernière chose, tout se sait un jour, y compris le déroulement de cette soirée. Si par accident votre client et vous partez dans une bringue monumentale, votre employeur en entendra parler tôt ou tard et s'en fera sa propre opinion. L'employeur de votre client aussi, ce qui peut être tout aussi gênant pour vous.
Discuter travail ou ne pas le faire ?

Il n'est pas toujours souhaitable de parler travail en ce genre d'occasions. En tous les cas, il vaut mieux en laisser l'initiative à votre client puisqu'il vous a convié à un moment de détente. Lui ramener du travail à table ne serait pas très délicat.

Si vous le pouvez, trouvez un sujet partagé et sans risque. Football, musique, littérature, voitures, il y a certainement quelque chose. Laissez vivre la discussion, ça ne fait pas de mal. Évitez par contre les sujets à controverses, polémiques, propices aux excès de passion, ou simplement trop personnels. Si votre client amène de tels sujets, sortez-en habilement. Il vous faut le sentir au cours de la discussion, car cela dépend de chacun mais aussi des circonstances. Tout ce qui peut générer un agacement, une aversion, ou un affaiblissement de votre position doit être évité. Vous continuerez de travailler avec ce client, demain comme plus tard, et vous aurez bien du mal à avancer si vous vous irritez mutuellement ou s'il sait des choses sur vous que vous préfèreriez qu'il ignore.

Et si votre client commence à parler travail, tout dépend de votre capacité à le faire en cet instant. Si vous êtes fatigué ou pas en condition, tâcher d'esquiver en vous en tenant aux lieux communs. N'ayez pas l'air de fuir le sujet, car cela inquièterait votre client ou lui donnerait une fausse idée de votre compétence, ce qui pourrait vous desservir dès votre réunion du lendemain. Si par contre vous êtes en situation de bien tenir cette discussion, tout va bien. Prenez simplement garde à bien gérer le "off".
Bien gérer le "off"

Il est courant d'échanger quelques informations "off" lors de ce genre de moments. Elles peuvent consister en des informations relatives aux projets comme aux personnes qui y sont impliquées. Cela peut se révéler une aide précieuse, mais soyez très prudent car ceci est à double tranchant. Ayez toujours le réflexe de vous poser la question suivante : « si demain on en reparle au boulot, ou si mon boss venait me faire état de cette discussion, est-ce que j'en éprouverais la moindre gêne ou inquiétude ? ».

Si la réponse est oui, laissez tomber : ne divulguez pas cette information, ou bien si c'est votre convive qui la divulgue, trouvez un moyen détourné et poli de ne pas le laisser finir. Il y a des informations qu'il est gênant de recevoir. Autant ne pas les recevoir.

Si la réponse est non, par contre, c'est une excellente chose. Vous travaillerez sans doute plus facilement avec ce client à l'avenir, et vous venez peut-être de gagner beaucoup de temps ou d'énergie. Cette soirée, en plus d'être agréable, est également utile.
Un verre ça va... etc

Evitez de trop boire comme de trop faire boire votre convive. La notion de "trop" varie selon les personnes : cela ne vous interdit pas d'être bon vivant dans les limites de l'acceptable si l'ambiance et le client s'y prêtent, la seule règle étant de ne pas risquer d'enfreindre par laisser aller les règles ci-dessus - et d'avoir le droit de conduire si vous mêmes ou votre client êtes motorisés.

Dans un prochain billet, j'ai l'intention de vous présenter une fail-list réelle (mais anonymisée bien sûr) des règles ci-dessus. A suivre, donc...

Notes
[1]C'est rare, mais cela arrive quelque fois. Attention tout de même aux libertés que l'on croit pouvoir prendre. Se rendre compte de son erreur peut se révéler très gênant en ces circonstances, et peut surtout avoir des conséquences durables.
[2]Non, je n'ai pas été confronté à ça personnellement. Par contre, un ancien collègue s'est vu proposer une session boîte à strip-teases et plus si affinités.
[3]« L'homme supérieur est amical sans être familier ; l'homme vulgaire est familier sans être amical », Confucius.

La carotte et le bâton

2010-01-15T18:24:00.004+01:00

C'était à mes débuts dans la gestion de projets en MOE, tandis que je travaillais pour une petite SSII dont l'activité consistait pour partie en la réalisation de sites intranet et internet.

Un mardi, en fin d'après midi, tombe une "mission sauvetage" : un client qui devait prendre livraison d'un site internet le lundi suivant se trouve bloqué. Son prestataire informatique l'a "planté"^[1].

Pascal^[2], mon directeur général, m'explique qu'il a lui-même négocié cette affaire, le client étant de ses amis.
Il me donne plus de détails. La mission consiste en approximativement cent cinquante pages web à réaliser. Nous devons livrer au plus tard le dimanche soir. En commençant le lendemain matin et comptant le week-end à venir nous avons cinq jours pour effectuer ce travail. Il m'affecte pour ce faire tous les techniciens de notre entreprise, soit approximativement vingt personnes. Enfin, il me dit ne pas douter qu'en faisant travailler mon équipe soirs et week-end je mènerai sans aucun doute ce projet à bien. Il me renouvelle sa confiance, et compte sur moi.

Je sens comme une sourde colère monter. Je la retiens un instant et m'interroge. Habituellement, ce type de site utilise des gabarits de page, tandis que les contenus éditoriaux sont stockés dans une base de données. Les gabarits sont en quelque sorte des pages intelligentes qui puisent leur contenu dans la base de données au moment de la visite de l'internaute. Cela permet de ne réaliser en tout et pour tout qu'une seule page vierge - un gabarit - de chaque type^[3]. Que signifie donc "cent cinquante pages à réaliser" ?

Je fais part de mon interrogation à Pascal qui m'en dit plus : le propos est ici de permettre au client de prendre livraison du site dès le lundi, et ce quitte à ce que pour aller plus vite les pages soient statiques et que le site soit par la suite refait en dynamique. En clair, quitte à ce que l'on utilise pas de base de données et pas de gabarits mais que l'on intègre le texte directement dans les pages, en multipliant le nombre de pages par le nombre de contenus publiés.

Evidemment, je me pose la question de savoir si le passage de statique à dynamique pourrait être un projet futur que l'on proposerait au client. La réponse est non. C'est le prestataire initial qui s'en chargerait. Notre mission se limite à ce dépannage et aucun apport d'affaire liée n'est à considérer. Pascal me dit enfin que le client nous rendra visite le lendemain matin à 9h et que je pourrai voir tous les détails avec lui.

Je sors de son bureau et réfléchis. De mon point de vue, plusieurs problèmes se posent:

- un tel travail, cela s'organise et se prépare. Or je n'aurai aucun élément avant le lendemain matin, tandis qu'il me faudra distribuer le travail à vingt personnes et de façon à ce que chacune d'entre elles puisse avancer indépendamment de toutes les autres.

- nous sommes déjà tous affectés à d'autres projets pour lesquels nous sommes engagés à des dates de livraison. Comme nous ne sommes pas particulièrement en avance sur ces travaux^[4], nous allons nous mettre en difficulté avec des clients réguliers et qui nous apprécient, sans avoir de raison valable à présenter pour justifier nos retards.

- on me demande de faire travailler une équipe soirs et week-end, toutes affaires cessantes et dès le lendemain, mais sans m'avoir parlé de contrepartie ni leur laisser le temps de s'organiser. Je trouverais légitime d'en appeller à la générosité du personnel si nous avions rencontré un problème soudain et mettant l'entreprise en danger - un problème de qualité sur un produit livré, par exemple, et qui pourrait nous faire perdre un client ou lui devoir de lourdes pénalités, donc risquer nos emplois. Mais en l'occurence il ne s'agit pas de cela. Il s'agit de faire plaisir à une connaissance de Pascal ainsi qu'à Pascal lui-même. Demander aux membres de l'équipe de prendre sur leur temps personnel, d'annuler leur rendez-vous privés, de ne quasiment pas voir leur famille cette semaine là et pour ces seules motifs m'apparaît déplacé et incongru^[5]. Du point de vue de l'entreprise, je ne cautionne pas non plus cette décision : ce service sera certes facturé lourdement, mais je ne suis pas convaincu de la rentabilité de l'opération au final vu que nos autres projets en subiront les conséquences. Nous nous comportons en bricoleurs, ce que je ne peux cautionner.

- les vingt personnes qui me sont soudainement allouées sont de tous profils. Certains, comme les développeurs base de données, ne sont pas des monteurs de pages HTML. Ils ont la capacité de le faire mais cela n'a absolument rien à voir avec leur fonction. S'ajoute à cela le fait que parmi ces 15 personnes, toutes n'ont pas la rigueur nécessaire à la réalisation d'un grand nombre de page dans un délai bref. Je m'attends à de nombreux problèmes de mise en page ou d'affichage engendrés par de trop rapides opérations de copier/coller.

- dernier point, si développer et tester toutes ces pages est déjà une chose^[6], il faut également faire tester le produit fini au client et obtenir de sa part la signature du "procès verbal de recette"^[7]. Or cela prend du temps.

Je suis de plus en plus agaçé. Cette affaire est déjà vendue au client, sans même avoir tenté de négocier le délai de livraison - ce qui pourtant eut pu s'entendre dans un contexte d'aide face à un impondérable - et le tout sans que l'équipe technique n'ait été consultée quant à la faisabilité de l'opération.

Je retourne voir Pascal :
« Qu'est-ce que tu prévois, pour l'équipe, en compensation de leur soirs et week-end ?
- Ils récupéreront leurs heures, ne t'inquiète pas. Ils prendront des jours la semaine prochaine pour rattraper les soirs de cette semaine et ce week-end.
- Un jour de semaine, ça ne rattrape pas un jour de week-end. Ca ne rattrape pas les soirées non plus. Puis il faut qu'ils s'organisent, ils ont une vie à côté du boulot. Puisque l'on facture ce dépannage, on pourrait donner un prime à ceux qui seront restés, ou leur proposer une double récupération, ce serait la moindre des choses.
- Ah non, non! Tu comprends, proposer une prime, c'est un peu la carotte et le bâton... "je fais des heures sups pour avoir une prime", non, il faut de la motivation ! »

La carotte et le bâton, les bras m'en tombent ! Je ne trouve rien à répondre tant je suis scié. Mais il est inutile de poursuivre cette discussion relative à l'équipe, je perds mon temps. L'affaire étant quant à elle déjà vendue, il est trop tard pour refaire le monde en la remettant en question.

Je laisse Pascal et rentre chez moi. Chemin faisant, je réfléchis.
Cette affaire est indéfendable, on aurait très bien pu ne pas l'accepter, on aurait même mieux fait. Et lorsque l'on attend des gens un investissement personnel fort, on doit s'en donner les moyens.
Au vu du positionnement de Pascal, hors de question que qui que ce soit reste ce week-end. Quant aux soirs, ce sera tout le monde dehors à 20h.

Le lendemain matin, j'arrive avant la cliente et l'équipe. Je vois André, notre directeur de production. C'est lui qui en temps normal affecte le personnel aux différents projets, en fonction des besoins exprimés par les différents chefs de projets. C'est également lui que l'on consulte avant toute planification afin de prendre connaissance des disponibilités de chacun.

Il a, lui aussi, appris la nouvelle la veille au soir, et ne cautionne pas plus que moi la décision d'avoir engagé l'entreprise dans cette affaire. Je lui fait part de ma discussion avec Pascal ainsi que de mon intention de ne demander à personne de travailler soirs et week-end. Comme souvent, André prend acte sans faire de commentaire.

Arrive la cliente. Nous nous entretenons brièvement, André, elle, et moi. André me demande de nous résumer les contextes, enjeux, et risques liés à ce projet. Je ne me prive pas et fais état d'un contexte d'urgence et d'improvisation, d'un enjeu faible - le prix de facturation, qui s'il est élevé en terme de tarif horaire ne changera pas la vie de l'entreprise - et d'un risque élevé de ne pas terminer dans les temps doublé d'un risque de rencontrer des problèmes de qualité produit.

A ma surprise, André ajoute qu'il voit un risque supplémentaire à son niveau de gestion : celui de voir toute la production désorganisée pendant une à deux semaines. Il précise : « Cette semaine-ci pour réaliser le travail dans l'urgence, et la semaine qui suit car toute l'équipe sera soit épuisés soit en récupération en fonction de la surcharge de travail que ce projet va engendrer. ». Je le remercie intérieurement de se positionner de la sorte et face à la cliente.

La cliente, quant à elle, réprime un mouvement d'embarras. Elle n'a pas plus que nous choisi cette situation, ce n'est pas elle qui a appellé Pascal à l'aide, c'est sa direction. Elle est cependant professionnelle, et ne se laisse pas déstabiliser par le tour que prend notre entrevue.

Elle me montre le travail à réaliser. Les maquettes sont assez simples, et le nombre de types de pages différents pas trop élevé. Les contenus éditoriaux sont nombreux mais dans un format courant^[8] ce qui permet de copier-coller sans conversion préalable. Ca c'est une bonne nouvelle. Enfin, il y a quelques pages particulières dont les fonctions demanderont un peu de programmation mais qui ne devraient pas être trop difficiles à tester.

Je mets rapidement mes idées au clair. Il est impensable de distribuer ce travail à vingt personnes sans que cela ne génère une attente invraisemblable entre les uns et les autres, voire une gêne comparable à celle d'un trop grand nombre de personnes dans une cuisine. Mais on devrait pouvoir se débrouiller à dix.
Pour certains types de pages, faire un gabarit dynamique associé à une base de données demandera moins de travail que de réaliser toutes les pages une à une. Il faudra copier coller les contenus directement en base. Pour d'autre types de pages au contraire, décliner des pages statiques sera probablement le plus rapide. Je demande à la cliente de vérifier que techniquement cela ne pose pas de problème. Elle passe un coup de fil et me le confirme.

André et moi allons voir l'équipe. Nous leur expliquons le problème tout en sachant qu'il ne peut être bien reçu. André prend le soin de mettre en avant mon refus de faire travailler l'équipe soir et week-end, contrairement au souhait de Pascal. Si cela aide à faire passer la pilule, une partie de l'équipe s'inquiète tout de même de la mise en pause des autres projets. Une partie seulement, car tout le monde n'est pas si consciencieux.

Nous nous mettons au travail. Les indications données par la cliente ont l'avantage d'être claires. Elle n'est pas plus agréable que ça mais elle fait bien son boulot, répond aux questions, se renseigne par téléphone lorsqu'elle ne peut répondre par elle-même. Cela permet d'avancer.

Mercredi soir à 20h, nous avons fait un bon quart du travail de réalisation de pages statiques et nous avons mis le système de gabarits en place. Comme nous avons réellement commencé en milieu de matinée, on peut dire que les choses se passent bien.

Jeudi soir, nous n'avons fait que la moitié du travail de réalisation statique. Nous perdons du temps sur certaines pages assez spécifiques et donc la réalisation pose problème. Côté pages dynamiques, les choses se passent mieux : l'équipe copie-colle, copie-colle, et copie-colle à tours de bras. Et s'en plaint également, ce que je peux comprendre.

Vendredi midi, le travail est terminé concernant la partie dynamique, ce qui permet de mettre les bouchées doubles sur les pages statiques. Pendant que celles-ci sont réalisées, la cliente et moi commençons les tests de ce qui est déjà réalisé. Le soir, les dernières pages statiques sont terminées vers 20h30.

Samedi matin, livraison. L'équipe ne travaille pas, je peux faire cela tout seul. Et par chance, je peux y travailler depuis chez moi grâce à un accès distant à notre réseau d'entreprise. A tête reposée, quelques tests me permettent de trouver deux ou trois bugs mineurs que l'on aura certainement à prendre en garantie si le client les trouve également. Mais je découvre également un bug majeur : un problème sur le gabarit avec certaines données entrées la veille au soir. J'éprouve une soudaine colère : celui qui a fait cette partie m'a garanti l'avoir testée plusieurs fois, la veille, or il est clair qu'il ne l'a pas fait. S'il ne m'avait pas donné cette garantie, j'aurais testé par moi-même, et aurais pu effectuer la correction nécessaire. Ce matin, je n'ai ni les outils nécessaires, ni les clefs de nos locaux, je suis donc coincé. Je me demande pourquoi je me bagarre pour que l'équipe ne fasse pas trop d'heures lorsqu'elle me met en situation difficile en échange. J'envoie un mail assez sévère au développeur concerné, ne pouvant lui téléphoner. Je n'en ai pas encore conscience, mais j'ai tout à fait tort de faire cela : la prestation a été définie de façon aberrante, a été menée de façon toute aussi aberrante, il est donc normal qu'il y ait des problèmes. Ce développeur, avec qui je m'entends très bien, me pardonnera mais n'en sera pas moins blessé ; il en restera toujours quelque chose dans nos rapports. Je l'ignore encore, mais cela sera l'une de mes plus importantes leçons de management, mais je regretterai toujours de l'avoir apprise au travers d'un échec de rapport humain.

Une fois l'empaquetage fait et testé à son tour^[9], je le dépose dans un répertoire de notre FTP que je dédie au client, puis lui envoie un mail pour l'informer qu'il peut télécharger et installer le produit. Je m'occupe également de la paperasse : procès verbal de recette à retourner signé, documents internes, etc. Tout est terminé vers 13h.

Lundi matin, Pascal vient nous rencontrer sur le plateau. Il nous félicite tous, mais pour nous cela sonne mal et ne tombe pas bien. S'il est ravi, nous ne le sommes pas. Evidemment, nous sommes contents de nous en être sortis, cependant, nous sommes tous en retard sur les autres projets, et nous sommes agacés d'une semaine qui, si elle n'a été que raisonnablement surchargée en terme d'horaires, s'est vraiment déroulée à la chaîne^[10], et ce sans autre bonne raison que le souhait de faire un coup dont l'éclat n'est même pas très important.

Lorsque Pascal en a terminé et s'en retourne à son bureau, je commets l'erreur d'indiquer à l'équipe le détail du travail abattu. Certains sont amusés, la plupart indifférents, tandis qu'André s'en trouve d'autant plus agacé. Il m'en fait part, et me demande de ne plus avoir recours à « ce genre d'incentives » à l'avenir. Je suis surpris sur le moment car ce n'en était pas une, mais plus tard, avec le recul, je me dirai qu'il avait raison : le simple fait que cela puisse être perçu comme tel justifie qu'il faille s'abstenir.

A partir de ce moment, l'équipe reprend une activité normale. De mon côté, je corrige rapidement le problème rencontré samedi, et relivre. Puis nous n'entendons plus parler de cette affaire.

Quelque jours plus tard, je découvre que le site à été mis en ligne. A la fin du mois, j'apprends que nous avons reçu le paiement. Celui-ci est inférieur à ce que Pascal avait initialement calculé puisque nous avons travaillé à dix et non à vingt. Nous avons gagné, en plus de la facturation normale journalière de nous dix, soit 30 jours/homme, l'équivalent de 10 jours/homme. Nous sommes en retard sur deux projets et cela risque de poser des problèmes de qualité assez importants. Tout cela ne valait décidément pas le coup...

Notes
[1]Je n'en saurai pas plus.
[2]Ce prénom, comme les autres, à été modifié.
[3]Ceci est tout à fait comparable au fonctionnement d'un blog. Une fois la maquette créée, le rédacteur crée ses billets en texte brut et ne se soucie de la mise en page que dans les cas particuliers. Lorsque l'internaute consulte le billet, celui-ci est automatiquement mis en page par le logiciel de blog. La différence avec un site d'entreprise est qu'il y a plus un grand nombre de gabarits, chacun ayant ses fonctions et ses spécificités.
[4]Comme c'est bien souvent le cas. Le client est souvent pressé d'être livré ; s'aligner sur le délai qu'il demande permet au service commercial de remporter l'affaire plus facilement. Cela pourrait faire l'objet d'un autre billet.
[5]D'autant que cela peut également engendrer un coût non négligeable : baby sitter pour les uns, leçons de conduite annulées sans remboursement pour les autres, sorties dont les tickets sont réservés et non remboursables, et j'en passe.
[6]Tester une page consiste en vérifier son bon affichage, en s'assurer que le texte est fidèle à celui transmis par le client. Cela implique également de tester chacun des liens, boutons, et autres fonctions que chaque page comporte. Cela prend du temps, or bien qu'il s'agisse d'une "mission sauvetage", le client n'est pour autant pas disposé à ce que soit mis en ligne une produit de mauvaise qualité. Et il a bien raison.
[7]Ce document constitue la trace écrite de l'acceptation du produit par le client. Le client y reconnait le produit conforme à sa demande. C'est comparable aux certificats de bonne fin de travaux que l'on trouve dans le domaine du BTP.
[8]Les contenus éditoriaux nous sont souvent livrés dans des formats adaptés au monde de l'édition papier, mais exotiques pour nous autres informaticiens. Cela pose de multiples et chronophages problèmes de conversion que l'on est bien content d'éviter ici.
[9]Il s'agit de l'opération permettant de donner à l'application développée une forme livrable : les nombreux fichiers qu'elle comporte sont rassemblés en un fichier unique et compressé et que l'équipe technique du client devra installer. C'est tout à fait comparable aux programmes d'installation des applications que l'on installe sur un PC de bureau.
[10]Et cela fait réfléchir à ce que doit être le travail à la chaîne pour ceux qui travaillent réellement dans ces conditions, tout le temps, et pendant des années. Pour nous, il ne s'est agi que de quelques jours, et encore, dans des conditions de bureau.

C'est la faute des SI !

2009-12-31T09:52:00.004+01:00

Il y a quelques temps, un ami m'expliquait la situation critique dans laquelle se trouvait le groupe pour laquelle il travaille. Différentes sociétés du groupe étaient amenées à fusionner, et avec elles, leurs systèmes d'information respectifs. La fusion était en retard, et posait de ce fait divers problèmes allant de la valorisation en bourse des titres du groupe à la tension et au climat délétère qui régnaient au sein de celui-ci. La position de mon ami, à cette époque, lui permettait de suivre d'un point de vue utilisateur l'évolution du travail accompli par le service informatique.

Lorsque j'ai demandé à mon ami la cause de ce retard j'ai obtenu pour toute réponse un lapidaire « c'est de la faute des SI^[1] ».
« Comment ça, la faute des systèmes d'info ? Sois plus précis, explique toi...
- Ils sont en retard ! Ils devaient livrer le nouveau système unifié, ils ne l'ont pas fait. C'est vraiment une bande d'incapables et de menteurs. »

Ok. Je n'ai jamais travaillé pour cette boîte, mais je peux imaginer que leur projet informatique est effectivement en retard. C'est assez courant malheureusement. Mais l'explication m'a semblé un peu réductrice. J'ai tenté de creuser :
« Pourquoi ? Il fallait qu'ils livrent quand ?
- Ils devaient livrer à [telle date].
- Et finalement, ils livreront quand ?
- Pas avant [telle autre date ; des mois plus tard].
- Ok. Effectivement, ça craint. L'engagement, pour la date initiale, il venait d'eux ?
- Mais non, t'es fou ! Eux voulaient livrer à [telle autre autre date ; encore bien plus tard]. Mais c'était pas possible, t'imagines pas. La direction leur a foutu la pression, ils ont bien été obligés de revoir leur copie. Finalement, ils devaient livrer à [date initiale] et ils n'ont même pas été foutu de le faire !
- Bah, ça m'étonne pas trop trop, du coup... La date finalement retenue ne tenait compte d'aucune réalité. Ils ont un peu été désignés volontaires, tu ne trouves pas ?
- Ouais, mais tu te rends pas compte, ça a été annoncé à la presse, et tout. Non, c'est vraiment n'importe quoi, ils sont nuls. Je te jure, tu viendrais passer une journée chez nous, tu verrais comme ils sont nuls ! »

J'ai compris à ce moment à quel point ce n'était pas gagné. Impossible de lui faire comprendre que la réalité ne se négocie pas. Peut-être, effectivement, que le service informatique de cette boîte a de lourdes lacunes, mais le seul fait d'obtenir une date par la contrainte et de l'annoncer à la presse est la preuve d'un cruel manque de réalisme. S'il s'agit d'une technique - très discutable - de management, n'est-ce pas une folie furieuse que de prendre ses désirs pour des réalités, à ce niveau ?

Nous avons poursuivi cette discussion, mais sans que rien de significatif ne s'en dégage plus. La conclusion de mon ami était que l'impératif justifiait la mise en place de moyens appropriés. La mienne était que rejeter l'intégralité de la responsabilité sur le département informatique révélait au minimum une faute de la direction générale : soit qu'elle accepte un service informatique qu'elle sait inadéquat et que pourtant elle ne modifie pas, soit qu'elle n'assume pas ses responsabilités quant aux conséquences de son imprudente annonce.

Evidemment, il est impossible de se faire une idée définitive sur une affaire sans en connaître le détail, or je ne connais que ce que mon ami m'a transmis. Aujourd'hui encore, j'ignore dans quelle mesure la proposition initiale du service informatique était raisonnable ou non.

Mais indépendamment de cela, c'est après le discours à l'emporte pièce qui m'a été tenu que j'en ai. Il m'a certes été tenu de façon particulièrement caricaturale cette fois-ci, mais dans son fond il n'en est pas moins courant. Il me pose un problème car il suggère l'alternative suivante :

si le délai proposé par le service informatique était déraisonnable, la direction générale n'avait pour autant pas les compétences nécessaires à déterminer seule un délai raisonnable. Pourtant elle n'a pas fait appel à une aide extérieure. Peut-être qu'elle devrait redéfinir son service informatique, mais elle est alors responsable de son inaction ou de son échec à conduire cette redéfinition. Torts partagés, donc.
si le délai proposé était raisonnable, il est stupide de vouloir le réduire en espérant ne pas rencontrer de problèmes, et ce même s'il y a d'excellentes raisons de souhaiter réduire ces délais. Torts exclusifs, en ce cas, mais pas ceux des SI.

Pourtant, le discours est que « c'est la faute des SI ». Ce qui est regrettable avec cette vision, c'est qu'elle est contre-productive, en plus d'être désagréable. Elle mène en effet les services informatiques et les servives utilisateurs à la plus grande méfiance réciproque. Or lorsqu'il n'y a pas de confiance, chacun tâche de se couvrir, de ne pas prendre le moindre risque. Chacun s'en tient à ses prérogatives, strictement, et à l'exclusion de toute initiative. S'il y a la moindre ambiguité, on s'empresse de ne rien faire en attendant la précision écrite permettant de résoudre cette ambiguité. En attendant, rien ne se passe, et chacun fait état du fait qu'il est bloqué par la seule faute de l'autre.

C'est la stratégie de l'échec. Mais bien que tout à fait improductive, cette situation engendre un gaspillage de temps et d'énergie conséquent et dangereux. Du travail fait sera à refaire, ou bien demeurera tel qu'il est mais ne sera pas exploitable. Des dates annoncées seront dépassées. Parce que l'autre n'a pas été assez précis. Parce qu'il n'a pas répondu assez vite. Parce qu'il a mal compris. Parce qu'il est mauvais.

On préfère aller vers un échec complet dont on peut tenir l'autre responsable plutôt que d'assumer un succès modéré dont on risque d'être tenu responsable de la modération. Au risque, pourtant, de mettre l'entreprise dans une difficulté telle qu'il y ait des retombées nuisibles au personnel - gel de salaires, licenciements économiques et autres.

Lorsque les choses en sont là, l'issue ne peut venir que du dessus car les intervenants ont atteint leurs limites. Ils ont perdu de vue l'objectif pour ne focaliser que sur eux-mêmes et leur service. Les choses ne se débloqueront pas d'elles mêmes ; il n'y a que la direction commune des services en question qui puisse arbitrer, faire intervenir des renforts extérieurs si nécessaire, ou pourquoi pas commander un audit afin de déterminer comment améliorer les choses. Si elle ne le fait pas et laisse les choses s'enliser, l'échec est alors inévitable.

Qualifier un échec d'exclusivement imputable « aux SI » (ou à tout autre service) ne veut donc simplement rien dire. Cela ne fait que réveler le blocage de la situation, l'atteinte de limites des intervenants impliqués. La direction devrait intervenir mais tarde à le faire, soit qu'elle s'y prépare, soit qu'elle est défaillante.

Pour avoir déjà vécu cela ailleurs - il s'agissait en l'occurence de la seconde option - je n'aimerais pas travailler dans la société de mon ami.

Notes
[1]Pour "Systèmes d'Information". Il s'agit du département informatique de l'entreprise.

Oui, le client à le droit de changer d'avis. Mais cela se gère...

2009-12-01T17:26:00.006+01:00

C'est un scénario assez classique : alors que vous êtes bien avancé dans la phase de développement de l'application commandée par votre client, celui-ci souhaite vous voir prendre en compte des modifications. Ces modifications, parfois lourdes, ne peuvent être intégrées sans avoir préalablement étudié leurs conséquences, et éventuellement refait une partie du travail de conception et développement.

S'il existe une procédure d'entreprise pour gérer cela et qu'elle est appliquée, tout va bien. Mais pour ce que j'ai pu observer, ce n'est pas toujours le cas.

Que faire en l'absence d'une telle procédure ?

J'ai pu expérimenter ce qui suit sur des projets "one shot" de quelques centaines de jours/homme ainsi que des projets en évolution constante de l'ordre de 1500 jours/homme/an, pour des équipes de 5 à 8 développeurs.

Mon objectif n'est pas de présenter une méthode infaillible - sans doute a-t-elle ses failles, mais plutôt un retour d'expérience qui j'espère pourra être utile.

S'il est rédigé sous la forme d'un guide pratique à l'usage du débutant en gestion de projets MOE, il n'en est pas moins pas moins perfectible. Aussi, que vous soyez client, développeur, commercial, chef ou directeur de projets, n'hésitez pas à me faire part de votre propre retour d'expérience.

En premier lieu, informez votre équipe.

Une fois reçue la demande de modifications de votre client, informez votre équipe. Ses conseils seront précieux, et le fait qu'elle puisse penser à ces modifications en tâche de fond, le temps que les choses se mettent en place, peut se révéler très utile, d'excellentes idées pouvant germer.

Mais rassurez-là également, sans quoi cette demande de modification sera mal perçue.

Presque chaque fois, j'observe que les demandes de modifications tardives engendrent une réaction épidermique de la part des équipes de développement.

Pour en avoir souvent parlé avec les équipes dont j'ai eu la charge, et pour l'avoir ressenti moi-même lorsque j'étais développeur, cette réaction est essentiellement provoquée par l'anticipation du stress et de la désorganisation engendrés par le fait de devoir modifier l'application dans l'urgence. La crainte sous-jacente tient aux anomalies et dysfonctionnements pouvant résulter de la mauvaise évaluation des conséquences des modifications en question, et qu'il faudrait alors corriger dans l'urgence... au risque de créer de nouveaux problèmes, les conséquences de chaque correction étant elles mêmes mal évaluées.

En plus d'être anxiogène et apparemment sans fin lorsque l'on y est confronté, ce cercle vicieux pose de nombreux problèmes. Pour n'en citer que trois:

- problème contractuel dû à la perte de cohérence entre le fonctionnement réel de l'application et celui décrit dans les spécifications fonctionnelles et techniques,

- problèmes fonctionnels et techniques dus à la perte de cohérence des plans de tests destinés à vérifier le bon fonctionnement du produit,

- problèmes techniques dus à la faible maintenabilité du produit résultant. Et qui engendrent de futurs problèmes opérationnels et budgétaires du fait de l'accroissement de la charge de travail et des délais de maintenance.

Cette crainte est donc tout à fait légitime. Si elle se traduit par une réaction épidermique, ce n'est pas tant par mauvaise volonté de votre équipe que par spontanéité naturelle.

Il convient donc de rassurer votre équipe en lui faisant savoir ou en lui rappellant que vous êtes bien au fait de ces choses, et que vous gérerez la demande client de façon à ne pas laisser un tel cercle vicieux s'installer. Et tenez parole ; d'une part c'est la moindre des choses que vous lui devez, et d'autre part vous jouez votre crédibilité.

Pour régler le problème, ne peut-on pas refuser d'emblée toute demande tardive ?

Non. Le client est fondé à changer d'avis s'il s'aperçoit s'être trompé dans l'expression de son besoin. Il paie - souvent cher - un produit sur mesure, et ne peut concevoir que ce produit ne lui convienne pas, surtout lorsque dans son esprit il est encore temps de changer les choses. C'est que le client n'est pas technicien et n'a pas nécessairement conscience de la portée de ce qu'il demande.

Un refus catégorique est donc inacceptable du point de vue du client. Il ne manquerait pas de générer une pression intenable et contre-productive qui pourrait vous conduire à finalement devoir accepter la modification et la réaliser dans des conditions de nature à justifier toutes les craintes de votre équipe. Ceci aurait également toutes les chances de vous mettre dans votre tort si l'affaire escaladait et se trouvait négociée de direction à direction.

Mais ce n'est parfois qu'une question de forme. Dès lors que le client se rend compte des conséquences de sa demande, il peut changer d'avis de lui-même si ces conséquences sont déraisonnables^[1]. La meilleure chose à faire est donc d'étudier la demande, d'en mesurer l'impact sans en rajouter, et de la faire entrer dans un cadre acceptable par vous comme par votre client.

Du point de vue de la maîtrise d'oeuvre, quel est ce cadre ?

Plus tard une modification doit s'inscrire dans le processus de développement, plus celle-ci peut se révéler lourde : la modification demandée doit être rendue faisable, ce qui peut impliquer de revoir tout ou partie de l'application. La demande doit donc être analysée pour en saisir la portée. Une fois l'analyse effectuée, une phase de conception est nécessaire avant de passer à la réalisation car une partie du développement déjà effectué se trouve à refaire sous une forme différente.

Le client doit lui aussi vouer le temps nécessaire à la gestion de sa propre demande : il est l'éditeur des cahiers des charges et des spécifications fonctionnelles, or ces documents doivent être remis à jour pour intégrer les modifications demandées.

Prenons exemple sur un objet réel : si l'application est un lecteur de CDs, et qu'à la moitié de sa réalisation il s'agit d'en faire un lecteur de cassettes^[2], l'analyse montrera que le boitier physique de l'appareil, les parties mécaniques, têtes de lecture et moteurs, seront nécessairement à revoir, mais peut-être pas les parties amplification ou connectique. Seules les parties nécessaires seront re-conçues puis réalisées. La documentation fonctionnelle comme technique du produit devra être revue en conséquence, ainsi que son manuel d'utilisation.

Des contraintes opérationnelles peuvent se poser car se plier aux contraintes techniques peut nécessiter la mise en place d'une organisation particulière : la composition de l'équipe peut nécessiter des modifications, vous pouvez également avoir besoin de machines supplémentaires de développement ou de test, tout comme vous pouvez avoir besoin de serveurs d'application, de SGBD, ou de quelque autre produit que ce soit en fonction de la demande. Le délai fait aussi partie des contraintes opérationnelles : outre le fait que l'analyse, la conception, la réalisation demandent du temps, vous pouvez rencontrer des obstacles organisationnels comme la disponibilité des ressources dont vous avez besoin.

Les contraintes budgétaires, enfin, doivent également être prises en compte. Le temps homme, le matériel, les logiciels, ont un coût. Votre temps à vous compte également, puisque le temps passé à gérer la demande n'est pas passé à autre chose. Les contraintes budgétaires ne se limitent pas à cela : vous pouvez également avoir des contraintes de date de facturation, de clôture d'exercice comptable, de pénalités liées à la qualité du livrable et/ou aux délais. Il se peut que vous ne soyez pas en mesure d'évaluer ces impacts par vous même ; tout dépend de la structure de votre entreprise. Vous pouvez avoir besoin de consulter vos interlocuteurs commerciaux en interne.

Tout les modification demandées doivent être examinée sous ces différents angles de vue, sans exception, sans quoi elles ne peuvent être réalisées convenablement.

Les modifications mineures ne font pas exception : dans le cas particulier d'une modification triviale (un mot à remplacer par un autre sur une page, par exemple), la phase d'analyse comme la phase de conception sont instantanées, tandis que la réalisation ne prend que quelques instants. Cependant, le schéma de gestion de la demande n'en est pas modifié pour autant : chaque étape est simplement immédiate ou presque.

Se forcer à respecter ce schéma, même pour des changements d'apparence mineurs, permet d'éviter de passer à côté d'implications techniques pouvant se révéler très coûteuses au final.

Quelle sont les étapes à suivre pour faire entrer la demande dans ce cadre ?

Ne considérez pas les modifications comme étant effectivement à réaliser dès réception de la demande client. Nous l'avons vu, votre client n'a pas nécessairement conscience de la portée de sa demande, si bien que vous devez en premier lieu l'en infomer pour qu'il décide en connaissance de cause.

Il faut donc commencer par la phase d'analyse de la demande : quels sont les systèmes ou sous-sytèmes impliqués, et dans quelle mesure ? Cette phase permet de se faire une première idée de l'ampleur des modifications demandées. A son issue, sans encore connaître précisément le coût et le délai de réalisation impliqués, vous en savez suffisemment d'information pour déterminer si ces modifications sont mineures ou majeures.

Ces termes sont subjectifs, et sont dépendants du contexte, de votre marge de manoeuvre, de l'entreprise, et parfois du client. Personnellement, je considère majeure toute modification dont le coût et le délai sont suffisamment élevés pour que mon employeur puisse m'en tenir rigueur si le bien-fondé de cette modification devait se trouver contesté par le client par la suite et sans que je ne puisse justifier du contraire. C'est en quelque sorte le risque maximal qu'il est raisonnable de prendre sur ses propres épaules.

- Si la demande est mineure :

Le budget, les délais, ne sont pas impactés par la demande. Un simple échange d'e-mail avec votre client suffit à garder trace avant que la modification ne soit effectuée.

Si cela se produit de façon régulière, par contre, suggérez à votre client de grouper ces modifications mineures en lots, et s'il ne le fait pas, faites le pour lui. Vous pouvez ainsi traiter le lot comme une seule demande, non plus mineure mais d'ampleur limitée.

- Si la demande est d'ampleur limitée sans toutefois être mineure :

Sur un projet classique, vous pouvez déjà la chiffrer précisément en terme de coûts et délais. Votre client aura besoin de cette information pour vous donner son approbation finale.

Il vous faut également vérifier si cela nécessite de revoir le plan de facturation, particulièrement lorsque la modification en question doit faire glisser une émission de facture d'un trimestre ou d'une année sur l'autre, ce qui peut poser problème à votre entreprise - quelques jours peuvent suffire ! Votre service commercial peut-être nécessaire ici.

En tous les cas, charge à vous ou a votre service commercial de négocier ces aménagements auprès de votre client et d'en prendre acte écrit avant de procéder à la réalisation.

Une fois l'accord obtenu, essayez d'obtenir de votre client la mise à jour de la documentation fonctionnelle de l'application, ainsi que celle du plan de test, avant de procéder à la réalisation. Si vous ne pouvez l'obtenir^[3], ne restez pas bloqué (quoique l'on en dise, vous ne pouvez pas vous le permettre, le plus souvent) et prenez acte écrit afin de vous couvrir, votre équipe et vous, en cas de problème futur. Un e-mail dans lequel vous décrivez de façon précise la modification demandée devrait suffire.

Sur un projet agile, de type Scrum ou XP, c'est plus simple : si la modification demandée n'implique pas de changement profond de la conception du produit^[4], la modification en question s'intègre au prochain sprint / à la prochaine itération.

- Si la demande se révèle majeure :

Informez votre hiérarchie. Pas nécessairement pour action de sa part - cela dépend de votre organisation interne et de la marge de manoeuvre qui vous est accordée, mais au moins pour vous couvrir si les choses venaient à mal tourner.

Ensuite, n'oubliez pas que votre client n'a certainement aucune idée de l'ampleur de sa demande, et que ceci est tout à fait normal. A ce stade, l'avertir du coût prohibitif et du délai qui serait engendré par la prise en compte de cette demande est nécessaire avant toute autre action. Ce moment peut être assez intimidant, surtout lorsque le client, sous l'effet de la surprise, le vit mal et sur-réagit.

Pourtant il faut l'avertir sans détour ni ambiguité : d'une part vous n'êtes pas coupable de l'ampleur de la modification demandée - c'est simplement un fait, une conséquence de la demande reçue - et d'autre part vous êtes responsable du projet que vous conduisez - s'il y a la moindre ambiguité dans votre communication et qu'un surcoût ou délai est à regretter plus tard, la responsabilité est vôtre.

Si vous donnez cet avertissement de visu ou par téléphone, gardez impérativement une trace écrite - un échange d'e-mail ou bien un document signé par le client, en fonction de vos habitudes de communication avec lui - toute aussi claire. Cela pourra se révéler utile, et parfois plusieurs mois après la fin du projet.

N'hésitez pas non plus à proposer des solutions alternatives.
La plus courante d'entre elles consiste en ne pas intégrer la modification demandée dans la version courante mais dans une version future du produit. Le client n'y pense généralement pas, ne "voyant" que la version en cours, alors que c'est souvent un bon moyen de satisfaire tout le monde. Cela permet de faire entrer la demande dans le cycle de vie normal du projet : elle sera intégrée à la prochaine spécification fonctionnelle, laquelle sera étudiée, chiffrée, puis réalisée suivant le processus habituel.

Enfin, si votre client réagit vivement à l'annonce de l'ampleur de sa demande tandis qu'il est honnête par ailleurs, pardonnez-lui pour cette fois : s'il vous fait cette demande de modification, c'est le plus souvent qu'il s'est trompé en exprimant son besoin initial. Or si cette demande est d'ampleur déraisonnable, il aura certainement des problèmes avec sa hiérarchie ou son contrôle de gestion, soit qu'elle ne sera pas prise en compte, soit qu'elle sera très onéreuse. C'est d'ailleurs en ce genre de cas qu'avoir gardé des traces écrites de vos échanges se révèlera le plus utile.

Si une fois informé votre client persiste dans sa demande, il le fait en connaissance de cause, mais la phase de confirmation n'est pas terminée pour autant : contrairement aux modifications d'ampleur limitée, c'est dès maintenant que vous avez besoin de la documentation fonctionnelle mise à jour de façon à intégrer les modifications demandées. A défaut, vous ne pouvez tout simplement pas avancer car il est impossible de mesurer l'impact précis des modifications sans en connaître tous les détails. Vous seriez en outre dans votre tort si une fois le produit livré, le client ne l'acceptait pas pour des raisons de non respect de la spécification fonctionnelle. Dans l'hypothèse où le document fonctionnel est mis à jour de façon trop imprécise, rien ne vous empêche de cadrer la modification par vous même par le biais de la spécification technique qui en est la traduction informatique dont vous êtes éditeur, mais ne faites rien avant obtention de la validation formelle et traçable de vos écrits par le client.

Si le client ne veut rien savoir et vous refuse la mise à jour de la spécification fonctionnelle ou la validation de vos modification à la spécification technique, il est simplement impossible de procéder à la modification demandée. Cela arrive rarement, heureusement, mais le cas échéant, ne cédez pas : si d'aventure vous vous engagiez sans cadrage suffisant, votre équipe pourrait voir toutes ses craintes justifiées et vous en seriez responsable. Des impacts financiers voire légaux pourraient également en résulter, et ce serait de votre fait. Vous avez déjà prévenu votre hiérarchie de cette demande de votre client et des difficultés qu'elle pourrait engendrer. Aussi, faites plutôt escalader l'affaire, sans dramatiser, car on ne peut en aucun cas vous reprocher votre fermeté dans ce cas de figure : elle est parfaitement légitime, vous avez pris toutes les dispositions nécessaire à la bonne gestion de la demande de votre client ; son refus de formaliser ne vous est pas imputable.

Lorsque l'on en est là, alors ça y est, c'est bon ?

Pas tout à fait mais presque. Le plus dur est fait !

Vous pouvez maintenant passer à la conception ; elle ne doit pas être négligée ici sans quoi vous risquez des problèmes techniques à n'en plus finir. Ensuite, vous pouvez chiffrer précisément et planifier la réalisation. Prenez un peu de marge, tout en restant raisonnable, car la tendance naturelle est généralement de minimiser l'impact des modifications.

Une fois le planning réalisé, il est vraisemblable que le surcoût et le délai additionnel engendrés nécessitent quelques discussions entre vous, éventuellement votre service commercial, et votre client. Un dernier effort est alors nécessaire : ne surtout pas céder à l'envie d'en finir avec cette histoire en réduisant vos estimations. Si des ajustements mineurs sont tout à fait légitimes, le coût et le délai que vous avez estimés sont le reflet d'une réalité à laquelle vous ne pouvez rien, et ne sont donc pas négociables... à moins que le client ne revoit le périmètre de sa demande à la baisse auquel cas vous devez reprendre le processus de prise en compte à zéro !^[5]

En conclusion

Du point de vue de la maîtrise d'oeuvre, il n'y a aucune justification à refuser d'emblée une demande de modification, même tardive. Celle-ci peut toujours être examinée et évaluée pour en déterminer les impacts, quels qu'ils soient.

Pour autant, s'il n'est pas possible de convenir de modalités de prise en compte réalistes avec le client, il vaut mieux rester ferme que de tenter le tout pour le tout : prendre en compte des modifications sans le faire méthodiquement ne peut que générer des problèmes dont vous seriez finalement responsable. Votre client n'en serait pour autant pas satisfait du fait des problèmes de qualités et des surcoûts engendrés. Et il aurait raison.

Notes
[1]Une demande impliquant de reprendre à zéro un projet en fin de phase de développement peut sembler déraisonnable au premier abord, mais ne l'est pas nécessairement : si, par exemple, le client fait face à une nouvelle contrainte légale et que celle-ci se révèle structurante pour le produit que vous êtes en train de développer, il n'est pas aberrant de tout reprendre à zéro pour l'intégrer puisque le produit serait inutilisable sinon. Cependant c'est un exemple extrême ; le plus extrême que j'ai eu à gérer, bien que très impliquant, n'allait pas jusque là.
[2]Ce qui serait une drôle d'idée, j'en conviens, mais qu'importe...
[3]Ce qui en pratique est assez fréquent. Je ne croise que rarement de bonnes spécifications fonctionnelles. Et encore plus rarement des plans de tests dignes de ce nom. L'idée reçue selon laquelle seules les PMEs sont concernées par ces carence est totalement fausse : il existe des PME's exemplaire en la matière, ainsi que de grandes entreprises inversement surprenantes.
[4]Sans quoi nous ne serions pas dans le paragraphe "Si la demande est d'ampleur limitée", n'est-ce pas ?
[5]Et cela se produit parfois !

3, 2, 1, fight !

2009-10-29T19:18:00.005+01:00

Nous autres informaticiens menons parfois une vie trépidante, si, si !

J'étais alors consultant technique sur une mission d'avant-vente. Il s'agissait d'une sous-traitance ; notre client - le gérant de Titagens, une agence de communication - mon commercial et moi-même avions rendez-vous chez Laboîte, le client final - le client de notre client donc^[1] - afin de l'aider à clarifier son expression de besoins^[2]. Laboîte nous avait déjà communiqué un document résumant l'essentiel de ceux-ci, l'objectif du jour était donc de lever les éventuelles ambiguités de formulation, d'expliciter les points flous, et de poser nos questions. Le budget alloué à ce projet par Laboîte nous était également connu, Titagens ayant obtenu d'eux cette information.

Mon commercial et moi-même avions horreur de travailler pour cette agence. Nous lui reprochions de sans cesse laisser entendre à ses clients qu'à l'issue de toute réunion de clarification du besoin, tout défaut d'objection de notre part pouvait être considéré comme une reconnaissance tacite du fait que la prestation souhaitée pouvait être réalisée dans le budget imparti. Nous avions beau préciser sans cesse, lors de ces mêmes réunions, qu'il nous fallait tout d'abord étudier ces demandes pour en évaluer les implications et donc le coût, ce qu'il est impossible de faire à la volée, cette précaution était toujours sapée en notre absence par le discours ultérieur de Titagens. Si ce comportement ne nous engageait pas faute d'écrit, il garantissait par contre un réel psychodrame chaque fois que nous communiquions notre évaluation définitive des coûts et des délais de livraison.

Ces crises se réglaient toujours de la même façon : notre directeur technique et le gérant de Titagens, amis personnels de longue date, renégociaient après coup plannings et devis afin de permettre à notre entreprise de remporter l'affaire en question. Mon commercial n'en était pour autant pas déchargé de la responsabilité de ces dossiers dont il héritait de la version révisée. Quant à moi, je conservais de la même façon la responsabilité de la conduite de projets, sur des plannings de réalisations ne correspondant pas à ceux que j'avais initialement fourni. Si effectuer des gestes commerciaux explicites aurait été tout à fait compréhensible et même bienvenu, tordre ainsi la réalité ne pouvait qu'engendrer des problèmes.

A cela s'ajoutaient d'autres irrégularités, notamment quant à la définition des responsabilités de la maîtrise d'oeuvre que nous étions et de la maîtrise d'ouvrage que Titagens était : ces responsabilités n'étaient pas écrite, ce qui permettait à Titagens de se comporter vis-à-vis de son client comme si nous nétions pas son fournisseur mais son partenaire.

Récemment, pourtant, un projet réalisé pour le compte de Titagens avait si mal tourné, et nous avait à tous coûté si cher - y compris en stress et épuisement - du fait de ce type d'arrangements, que nos deux sociétés avaient convenu par le biais de notre direction technique et du gérant de Titagens d'une sorte de "bonne résolution pour les projets à venir". Cette future commande de Laboîte était le premier dossier soumis à cette résolution. Mais ni mon commercial ni moi n'avions aucune confiance en son application.

Nous nous entendions très bien, ce qui nous permettait d'établir des stratégies. Notre répartition des rôles habituelle était que chacun ne s'occupe que de ce qui le concerne : lui des problématiques commerciales et contractuelles, moi des problématiques techniques et organisationnelles. Aujourd'hui, il prévoyait donc des difficultés, d'autant que le gérant de Titagens et lui se détestaient sans retenue.

Nous sommes arrivés sur le parking de Laboîte en même temps que le gérant de Titagens, venu avec l'un de ses employés. Une fois descendus de voiture, nous sommes salués rapidement, puis nous sommes rentrés dans le vif du sujet, l'ambiance n'étant pas aux plaisanteries d'usage. Après nous être brièvement accordés sur les objectifs du jour, mon commercial a réaffirmé notre position consistant en ne pas prendre d'engagement durant la réunion, mais uniquement après avoir analysé les éléments qui s'en dégageraient. Les demandes de Laboîte seraient simplement clarifiées puis notées en vue d'une évaluation ultérieure, sans que cela ne doive être interprété quelque acceptation tacite que ce soit.

La réaction du gérant fut cinglante :
« Et depuis quand tu poses des conditions ? ».
Elle eut évidement sa contrepartie, violente. Mon commercial avait de la voix :
« Tu ne vas pas nous enfler cette fois. Chaque fois que l'on est devant tes clients tu essaies de faire passer des choses en force, tu nous mets devant le fait accompli. Hors de question d'assister à la lecture des documents sans que [votre serviteur] ne puisse intervenir et que ce soit bien noté, ou que l'on réévalue la charge par la suite^[3].
- Tu te fous de moi ! - le gérant hurlait - Dis moi un peu, qui c'est le client ? Hein, qui c'est le client ? ».

Ils s'empoignèrent. Tous les deux, physiquement, au col, et en même temps. Ils beuglaient. Si je m'attendais à ce que ça chauffe entre eux, je ne m'attendais tout de même pas à ça. La scène était surréaliste, nous étions tout de même au boulot, avec un client, si difficiles que soient les choses avec lui...
Ils se relâchèrent un instant plus tard.

Le gérant refusait maintenant que mon commercial assiste à la réunion. J'ai alors ressenti l'envie de l'annuler, cette réunion stupide, de rentrer au siège social avec mon commercial et de reprendre les choses à tête reposée. Cependant, l'incident nécessitait que je prévienne notre direction. Pas notre directeur technique, mais l'adjoint de notre DG, avec qui il était plus facile de discuter. Je lui ai expliqué la situation au téléphone, rapidement.
« Bon. Dis à [mon commercial] de rentrer, me répondit-il.
- Et moi, tu veux que j'y ailles tout de même ?
- Oui oui, vas-y avec [le gérant de Titagens]. Fais comme d'habitude, ne t'engage pas, et a la limite, profite de l'absence de [mon commercial] pour éluder tout ce qui pourrait te déranger.
- Ok ». Et j'y suis allé.

Trépidante, je vous dis !

Et le soir, j'ai appris que mon directeur technique remplacerait, à la demande de Titagens, mon commercial sur cette affaire...

Notes
[1]Si cela vous semble compliqué ou nébuleux, rassurez vous... c'était le cas pour nous aussi ! Et vous n'avez pas lu la suite, encore !
[2]Celle-ci permet de définir la prestation puis de produire un devis.
[3]Je n'ai jamais dit que c'était un agneau.

Hommage à une cliente

2009-10-25T19:05:00.002+01:00

Ce matin là, Jean^[1], du service commercial, me remet le dossier d'une affaire venant d'être signée.

C'est pour un nouveau client. La prestation demandée est assez classique, et consiste en un outil de publication de bulletins d'informations et d'actualités.

La proposition de Jean est bien construite. Le budget est correct, l'engagement est tenable. Les éléments graphiques fournis par le client sont de bonne qualité. Pour une fois, je suis content ; mes seules réserves ne portent que sur des points techniques mineurs et qu'il devrait être facile de résoudre avec le client. Je prends rendez-vous avec lui, et nous convenons d'une réunion en leurs locaux la semaine qui suit.

Celle-ci se passe à merveille. Côté client, sont présents la responsable de la communication, le graphiste designer, et le directeur de la structure. Des gens courtois, agréables, constructifs. Nous avançons rapidement et traitons les différents points techniques.

Aux moments de pause, nous discutons de choses et d'autres, comme cela se produit parfois lorsqu'une relation de confiance s'établit. Jean annonce qu'il aura sous peu un fils. La responsable de la communication sourit et nous parle un peu du sien - il a maintenant 18 ans, il passe son permis, ah ! c'est que ça passe vite ! - puis nous nous remettons au travail pour régler les derniers détails de la prestation. Nous convenons de nous revoir deux semaines plus tard pour rendre compte de notre avancée.

Le développement se passe convenablement. L'équipe avance bien, et les rares problèmes nécessitant une décision client se résolvent facilement par e-mail et par téléphone. Le graphiste designer comme la responsable de la communication se révèlent toujours disposés à répondre à nos questions. Si tous les projets se passaient aussi simplement...

L'avant-veille de la réunion de suivi, le client m'appelle. Il s'agit du directeur de la structure ; il m'explique devoir repousser la réunion, probablement à la semaine suivante. Il s'excuse et promet de me recontacter dès qu'il sera en mesure d'en fixer la date.

Quelques jours passent. Le lundi suivant, je le recontacte de moi-même ; de nouvelles affaires ont été signées, et j'ai besoin de m'organiser. Nous convenons de nous voir le mercredi.

Cette seconde réunion est à l'image de la première. Nous présentons notre avancée. La designer nous demande quelques modifications mineures puis nous convenons des étapes suivantes. Une fois la réunion terminée, nous échangeons quelques plaisanteries d'usage. Jean nous révèle le futur prénom de son fils, puis apprenant que je n'ai pas d'enfants, la responsable de la communication plaisante sur le fait que nous, les hommes, avons la chance d'avoir toujours le temps. Comme la fois précédente, Jean et moi partons ravis.

Au moment de monter en voiture, le directeur nous rattrape. Son air soucieux contraste étrangement avec la réunion que nous venons de tenir.
« Je suis navré pour l'annulation de dernière minute, la semaine dernière, me dit-il
- Je vous en prie, ça n'a aucune importance, vraiment !
- Il faut que je vous dise quelque chose. C'est [la reponsable de la communication] qui me l'a demandé. ». Il prend une inspiration tandis que je me demande de quoi il s'agit.
« Son fils est décédé la semaine dernière. Elle souhaite que vous le sachiez, et m'a demandé de vous l'annoncer ne trouvant pas la force de le faire elle-même. Son souhait est de continuer à travailler comme si ne rien n'était. Sa seule demande est que vous ne lui reparliez jamais de son fils, ni de cette conversation que j'ai avec vous. »

Je reste interdit. Jean aussi.

Il y a cinq minutes nous plaisantions ; elle semblait d'excellente humeur, sans pour autant tomber dans l'exubérance. Nous avons même parlé du fils de Jean, de mes enfants futurs ; elle est parvenu à sourire alors qu'intérieurement, ce qu'elle vit doit être insupportable. Nous n'avons rien vu tant rien n'était perceptible.

Je remercie le directeur pour sa confiance et évidemment lui promet de respecter ce choix. Alors que Jean et moi saluons la force de la responsable, le directeur nous fait part de sa réserve : il craint que ce ne soit une forme de déni qui, s'il est louable, pourrait se révéler dommageable pour elle.

Je redoute la réunion suivante, craignant de ne pas parvenir à rester naturel. Pourtant, elle se passe bien, ainsi que toutes les suivantes.

Je ne sais si les réserves du directeur sont fondées, et ne veux pas me poser la question : si Jean comme moi apprécions cette cliente pour son honnêteté, sa sympathie, son amabilité et son professionnalisme, nous ne connaissons pas sa vie personnelle pour autant. Je n'ai aucune idée de la meilleure façon de gérer une telle tragédie. Simplement, je suis impressionné par autant de force, et j'estime cette volonté de ne pas laisser le drame prendre le dessus.

Notes
[1]Les noms ont été modifiés, pour rendre impossible l'identification des protagonistes de cette histoire. Certains faits, certains rôles, l'ont été également, mais cela ne change rien au fond.

Trois heures pour faire cent mètres (et monter trois étages)

2009-10-23T18:02:00.005+02:00

C'était un après-midi, tandis que j'avais 18 ou 19 ans. Je devais retrouver Nicolas, un ami de lycée, chez lui.

Il vivait dans une cité HLM de la banlieue est de Paris. Sa cage d'escalier était située en périphérie de l'ensemble, à cent mètres à peine de l'arrêt de bus.

Au point de départ de cette histoire, j'avais déjà parcouru cinquante mètres.

« Bonjour, jeune homme ! »
L'homme qui me lance ces mots est a peine moins jeune que moi. Il est assez fin, le crâne rasé à quelques millimètres, et vêtu d'un blouson rouge. Il me tend la main, et - réflexe idiot, mais qui sera sans influence sur la suite des événements - j'en fais de même.

Il n'est pas seul. Deux acolytes sont postés autour de moi. Eux non plus ne sont pas très âgés, et ont aussi le crâne rasé. L'un est fin et vêtu d'un jogging bleu, l'autre est plus épais et vêtu d'un blouson vert. Ils me semblent avoir surgi de nulle part, le terrain étant dégagé à cet endroit.

Tout comme Rouge, Vert et Bleu me saluent et m'offrent une poignée de main. Je comprends que celle-ci n'est destinée qu'à tromper l'attention d'éventuels passants ainsi qu'à informer les jeunes nous observant de loin que la situation est sous contrôle^[1]. Je l'accepte tout de même. Je suis seul et le terrain leur est acquis ; encerclé, je ne peux partir en courant, tandis que si je me montre offensif, je n'ai pas la moindre chance seul face au nombre. Bref, il n'y a pas d'autre choix que la négociation. Quelques jeunes s'approchent et nous observent. Certains font des signes pour appeler leurs amis restés au loin. Je me doute qu'il y aura bien plus de monde dans quelques minutes.

« Il faut que l'on discute, me dit Vert, tandis que Rouge me montre un couteau.
- C'est bon, les gars, je vous suis. Qu'est-ce que vous voulez ?
- Allons là bas, nous serons plus tranquilles. »
A défaut d'autre option, je me laisse guider par mon escorte. Nous avançons vers une cage d'escalier, qui se trouve être celle de Nicolas. En plus de ne pas être fier, j'enrage littéralement. Si près du but, c'est tout de même trop bête ! J'ai des envies de violence. Elles sont accompagnées d'un pénible sentiment de frustration^[2]. Cependant, je tâche de ne laisser transparaître aucune émotions. Un peu comme avec les chiens : s'ils sentent que l'on a peur ou que l'on est stressé, tout est fichu.

Je suis conduit dans le local des boîtes aux lettres. Bleu fait le guet à la porte, tandis que Rouge me menace de son couteau. Vert et lui commencent à fouiller mes affaires. Ils ramassent tout ce qui a la moindre valeur : mon argent liquide - pas grand chose en soi, mais beaucoup pour moi, ma carte bleue, mon ticket de Carte Orange et même deux timbres poste qui trainaient dans mon portefeuille. Ils prennent également mon blouson de cuir, dans lequel ils trouvent mon chéquier, mon Zippo, mes cigarettes et mes clefs. Je n'ai rien d'autre qui ait quelque valeur^[3]. Ils me rendent mon chéquier : « Ca, ça ne peut nous servir à rien, ça. », lâche Rouge, tandis que Vert ramasse mes affaires. Intérieurement, je me demande pourquoi ils ont pris les timbres alors que de toute leur vie ils n'ont probablement jamais écrit la moindre lettre.

Vert me questionne : « Et tu allais où, comme ça ?
- Voir un gars qui habite ici.
- Qui c'est ce gars ?
- Nicolas.
- Nicolas comment ?
- Nicolas..., Nicolas. Ma réponse est hésitante, ne sachant trop si donner son nom serait une bonne idée ; lui vit ici, je ne veux le mêler à quelque embrouille inextricable.
- Nicolas Nicolas... Connais pas. », conclut-t-il en faisant une moue.

Ils parlent entre eux mais je ne comprends pas ce qu'ils se disent. Ils décident manifestement de ne pas en rester là car ils me conduisent fermement hors du local, puis dans l'escalier de l'immeuble. Nous montons. Il s'agit de ce genre d'escalier typique des tours de béton, sans fenêtre, et destiné à n'être employé qu'en cas de panne d'ascenseur, d'incendie, ou d'agression lorsque l'on en est l'auteur. Aucune chance que qui que ce soit ne s'aperçoive que l'on est ici, et s'il devait y avoir du bruit, cela n'intéresserait personne.

Nous ne sommes qu'à un étage de chez Nicolas ; c'est tellement rageant ! Rouge, en me poussant, me fait trébucher sur une marche. Je manque de tomber et me rattrape à Bleu, un peu plus bas. Ce dernier imagine que je tente quelque chose, si bien que tous deux se mettent à crier et à m'injurier. Je reçois un coup de pied, mais il n'est pas très douloureux car peu adroit. Je crains vraiment que ça ne tourne mal mais je ne peux m'échapper, cerné par les trois lascars.

A défaut d'autre solution, je tente de les apaiser:
« Relax ! J'ai failli tomber lorsque tu m'as poussé. Je me suis rattrapé comme j'ai pu, c'est normal.
- Attention, on te tient à l'oeil », m'envoie Vert.

Rouge, pendant ce temps, regarde mon permis de conduire.
« Intéressant, ça, très intéressant... » dit-il, tâchant de se donner un air important, en lisant mon adresse.
« C'est quoi le code de la carte ? me demande-t-il alors,
- Non, ça je ne peux pas te le donner.
- Allez, vas-y, donne le numéro ! »
Il approche son couteau. Je suis tendu à bloc, je n'ai franchement pas envie de me prendre un mauvais coup - même involontaire, car à cet instant je commence à ne plus les croire enclins à la violence physique si les choses suivent le cours qu'ils en attendent. Ils me donnent l'impression de mauvais acteurs dans un film imaginaire, et dans lequel ils incarneraient de grands truands, tandis qu'en réalité ce ne sont que de petites frappes. Cependant, ils sont trois, je suis coincé dans un escalier dans leur cité, ils ont au minimum un couteau, et s'ils appellent leurs copains ces derniers pourraient être pire que ces trois-ci. Je leur donne mon code à quatre chiffres, au pire j'en suis quitte pour ce que la carte peut délivrer.

Puis, je ne sais pas pour quelle raison, je m'adresse a eux :
« Dites... l'argent, bon, c'est de l'argent que je n'ai pas, mais je peux faire avec^[4]. Par contre, mon blouson, c'est un cadeau de mon père. Et mon Zippo, c'est un cadeau de ma copine... ». Ce sont des mensonges ; j'ai acheté les deux.
Rouge fait un signe à Vert puis ajoute : « Rend lui le blouson. Rend lui le briquet aussi. ». Vert s'exécute. Rouge ajoute :
« On t'a guetté. Tu es venu en voiture. »
La question me fait sourire intérieurement tant elle est naïve, mais je ne peux le montrer.
« Non, je ne suis pas venu en voiture. Je suis venu en RER puis en bus.
- Comment ça se fait que tu es calme, comme ça ?
- Bah... c'est pas trop le moment de jouer les chauds.
- Tu t'es déjà fait agresser ?
- Non. Enfin, jamais de cette façon. Que des petits trucs. »
Je m'abstiens de le dire, mais je ne suis vraiment pas rassuré. Ca m'arrange qu'ils me croient calme car je sens ce genre de gus capable de partir en vrille à la moindre contrariété. Surtout lorsque phénomène de groupe aidant, chacun doit prouver sa valeur aux copains. C'est ce qui les rend dangereux : ils feraient sur un coup de tête ce qu'ils n'oseraient jamais faire de sang froid. S'ils devaient le regretter ensuite, intérieurement, ils trouveraient tout de même moyen de le vendre aux autres comme une action d'éclat.

Bleu s'en va, avec ma carte bancaire, tandis que Rouge me remets mes clefs et mes papiers. Il m'avertit que le code à intérêt à être le bon. Nous attendons.

Quelques minutes plus tard, Bleu est de retour. Il s'apprête à me rendre ma carte lorsque Vert l'interromp. Tous les trois parlent de nouveau entre eux sans que je ne puisse comprendre. Le ton monte ; ils ne sont visiblement pas d'accord. Je parviens à comprendre qu'il s'agit de ma carte.

Vert me dit de partir. Tant pis pour la carte, il me faudra de toutes façons faire opposition. Je ne demande pas mon reste et me dirige vers la porte du palier. J'ai à peine le temps de l'ouvrir et d'apercevoir la porte de Nicolas que Rouge m'attrape et me retient. Je pousse un cri, espérant que Nicolas l'entende, mais je suis vivement tiré dans l'escalier. Aucun bruit ne vient du palier, c'est raté.

« Non, on y va ensemble ! », crie Rouge, toujours en désaccord avec Bleu. Il désigne Vert : « Et toi tu restes avec l'otage. »
"L'otage" ! Je crois rêver. Je suis affligé par la médiocrité de ce cliché. Le film est mauvais, malheureusement je ne peux quitter la salle. Et Nicolas qui doit être à 10 mètres à vol d'oiseau ; foutus murs ! Je dois être là depuis une heure, il doit se demander pourquoi je tarde tant.

Nous montons quelques étages, puis Rouge et Bleu redescendent l'escalier, me laissant seul avec Vert. Quelques instants plus tard, alors que je commence à entrevoir une occasion de filer, d'autres jeunes arrivent depuis les étages supérieurs. Ils échangent quelques mots avec Vert, sans que je ne puisse comprendre. L'un d'eux m'adresse un regard, puis fait un signe de tête à Vert, comme pour lui indiquer une approbation ou une compréhension. Ils remontent, nous laissant de nouveau seuls. A tort ou à raison, j'abandonne tout projet de fuite. Pour l'instant, si les événements sont pour le moins angoissants, il n'y a pas de dommages corporels à déplorer, mais cela pourrait changer si jamais j'aggravais ma situation par quelque tentative malheureuse.

Mes sentiments sont confus et mêlés : je suis en colère, je me sens humilié, j'éprouve une crainte sourde quant à la suite des événements, je trouve mes agresseurs pitoyables, mais pourtant, je ne suis pas en mesure de me sortir de ce mauvais pas. Je n'ai pas le moral. Je pense à l'Albatros de Baudelaire et me fais pitié, me dégoûte un peu, moi qui en cet instant méprise mes agresseurs, voudrais les tuer, tandis que de peur je ne parviens même pas à m'enfuir.

Vert me demande alors :
« Pourquoi tu as les cheveux longs ?^[5] Je respecte, hein ! Simplement, on a les cheveux courts normalement.
- Ca veut rien dire, "normalement".
- Ca dérange pas les filles ?
- Non, non, pas du tout... »
Tout en répondant ceci, je suis stupéfait de la question. Evidemment, je sais bien que l'aspect, la tenue vestimentaire, le genre affiché, revêtent une grande importance pour les différents types de bandes, qu'elles soient de genre punk, rap, ska, skin, ou que sais-je tant il y a de stéréotypes auquels se raccrocher. Ma longueur de cheveux, mon blouson de cuir sur laquelle je porte une veste en jean aux manches coupées, sont évidemment autant de choses qui ont contribué à ce que je sois pris pour cible.
Mais tout de même ! Ces gars jouent les rebelles à longueur de temps, tout ça pour finalement me faire un tel aveu de conformisme.
« Tu fumes pas ? Tu peux fumer en attendant.
- Tu sais, tes amis et toi vous m'avez pris mes clopes.
- Ils sont partis en dehors du département, me répond-il en me tendant une cigarette et un briquet. C'est pour tirer plus d'argent.
- Ca ne sert à rien. La limite de la carte sera la même.
- Tu crois ?
- Oui, je pense. Enfin on verra bien, de toutes façons. »

Le temps passe. On s'ennuie. Je m'impatiente aussi, surtout me sachant si proche de chez Nicolas. Vert commence à me raconter sa vie, sans que je puisse déterminer s'il s'agit de sa vie réelle ou imaginaire - probablement un mélange des deux. Son passage en prison, son annulaire gauche tordu et bloqué suite à son agression par codétenu, à coup de fourchette. Puis il tente de chanter mais cesse vite, s'apercevant, un peu honteux, qu'il chante faux. Vert me questionne alors sur ma vie, et n'étant plus à cela près, je lui réponds honnêtement. Ma petite banlieue ouest, plutôt paisible. Le groupe de rock sont je fais partie. Le bac à la fin de l'année. Les problèmes familiaux, qui sans mettre ma vie en péril la ternissent un peu, par moments. Mais tout mis bout à bout, ça va, au final.
Vert écoute sans juger. Il pose parfois des questions, ou établit des parallèles avec sa propre vie. Puis il me parle de nouveau de lui, et ainsi de suite. Je dois admettre qu'en d'autres circonstances, cette discussion me plairait plutôt.

Le temps continue de passer, lentement. De temps en temps, passent quelques jeunes. De la même façon que plus tôt, Vert échange quelques mots avec eux. Après un long silence, Vert me propose, en désepoir de cause, de jouer à un jeu. Il s'agit que je grave le mur de l'escalier à l'aide d'une pointe qu'il me tend, pour qu'il devine ce dont il s'agit. Cela me fait soudainement prendre du recul quant à la situation ; je la trouve parfaitement hallucinante.

Bleu finit par revenir. Il m'invite à le suivre. Nous descendons tous trois l'escalier et sortons de l'immeuble. Rouge nous attend dehors, et derrière lui, se trouvent des dizaines de jeunes. Il me remets ma carte bancaire :
« Voilà. C'est fini, t'es libre. Moi, je m'appelle *****, et si un jour quelqu'un te cause des problèmes ici, viens nous trouver. ». Il me tend le poing pour que nous "checkions". Vert et Bleu me donnent à leur tour leur prénom et le fameux "check". Je suis comme étourdi. Les jeunes alentours nous observent en silence.

Mes agresseurs partent. Je rentre de nouveau dans l'immeuble, soulagé que tout cela soit terminé, et très en retard chez Nicolas. Je prends l'ascenseur cette fois ; un jeune monte avec moi et souris, sans montrer d'ironie. Il faisait partie des spectateurs, dehors. Sa voix est calme, bienveillante :
« Aïe aïe, hein ?
- Bah, qu'est-ce tu veux...
- Oui, c'était pas le bon jour ».

Arrivé chez Nicolas, je suis nerveux a posteriori, un peu comme lorsque l'on a échappé de peu à un accident de la route. Je fais opposition à ma carte bleue, et décide d'aller porter plainte le lendemain. Mes sentiments sont toujours mêlés tandis que je fais à Nicolas le récit de ce qui s'est produit, puis nous passons une fin d'après midi et une soirée normale, rejoins par quelques amis.

Le lendemain, au commissariat, le fichier photo ne me permet de reconnaître mes agresseurs. Je ne le saurai que plus tard, mais le dépôt de plainte pour agression avec menace d'une arme et l'opposition immédiate de ma carte me permettront d'être remboursé des 2400 francs retirés au distributeur.

D'une certaine façon, j'ai plutôt eu de la chance. Ceux sur qui je suis tombé n'étaient pas de véritables "méchants", bien qu'ils auraient souhaité l'être. Je leur en ai voulu un moment, évidemment, mais j'en retiens surtout de pauvre types, paumés dans leurs clichés de gang et de banditisme.

Foutus clichés que l'on nous vend.

Notes
[1]Comme dans toutes les résidences, qu'elles soient HLM ou non, les jeunes se connaîssent tous entre eux. Ils connaîssent les activités des uns et des autres, qu'ils les cautionnent ou non. Bref, c'est souvent l'inverse de leurs parents.
[2]« Je ne sais pas ce qui me retient [...]
- La peur peut-être ? »
Comment ça, ces mots ne vous disent rien ?
[3]Les téléphones portables n'existaient pas encore.
[4]Je voulais dire "faire sans", mais j'avais du mal à garder mes idées cohérentes. Mais s'ils ont compris ça va.
[5]En bon prototype de post-adolescent fan de rock metal, je les avais très longs et détachés, à cette époque.

De la juste évaluation du besoin

2009-10-20T18:09:00.007+02:00

La courte histoire qui suit se déroule il y a quelques années. Elle commence dans les locaux d'une petite société de services informatique.

Un matin, Pascal^[1], le directeur général, demande à me voir ainsi que Jean, l'un de mes collègues. Il nous confie un nouveau dossier, qu'il qualifie d'atypique :
« C'est un appel d'offres qu'il nous faut élaborer.
- Tu veux dire auquel il faut répondre ? me devance Jean
- Non, il faut l'élaborer sur la base de ce brief [qu'il nous tend]. C'est pour GrosClient. Ils ont besoin d'une application de gestion de documents en ligne, et doivent passer par un appel d'offre, c'est leur process interne. Nous, on peut les aider à l'élaborer pour y répondre ensuite ! »

Jean comme moi connaissons bien GrosClient. C'est une grande entreprise de l'ordre de la centaine de milliers de personnes avec laquelle il est assez difficile de travailler pour le petit prestataire que nous sommes. Des processus rigides, longs et complexes, des délais de paiement longs également. Si tout cela se comprend^[2] au vu de la taille de l'entreprise en question, ce n'est décidément pas ce qui nous arrange le plus ; et si cette entreprise fait effectivement vivre des milliers de prestataires comme nous, elle contribue également à nos difficultés, sans le faire exprès, comme un pachyderme vous broierait contre un arbre s'il lui prenait l'envie de vous faire un câlin.

En plus de cela, ce que décrit Pascal nous dérange un peu. Si nous réalisons une prestation d'aide à la rédaction de cet appel d'offre, il ne nous semble pas très sain d'y répondre ensuite. Ni même souhaitable, car notre structure n'a pas la carrure nécessaire à ce type de marché : du fait du système de pénalités de Grosclient et de ses délais de paiement, le gagnant d'un tel appel doit avoir une trésorerie conséquente, bien que cela puisse être rentable au final.

Mais qu'à cela ne tienne, ces considérations sortent de notre rôle. Nous en faisons état pour le principe mais n'avons pas la prétention de remplacer Pascal. Ce dernier ajoute : « Lâchez vous, quant aux fonctionnalités requises, soyez créatifs. Vous présenterez le dossier le 15, chez le client, à 9h. »

Pour l'instant, nous sommes surtout perplexes. Nous nous mettons au travail. Jean connaît bien le domaine fonctionnel concerné grâce à ses expériences passées. Pour ma part, je suis plus à l'aise sur les problématiques techniques. Cela nous permet en quelques jours de rédiger un cahier des charges qui nous semble perfectible, mais défendable. Nous sommes moins à l'aise quant à l'ampleur de la prestation ainsi définie : ce que nous avons établi sur la base du brief ramené par Pascal correspond-il effectivement aux besoins de GrosClient ? Il nous est difficile de savoir si c'est trop ou trop peu, ou simplement en ligne avec son objectif. Nous n'avons personne à contacter en l'attente de la réunion du 15, le correspondant MOA de GrosClient en charge de cet appel d'offres étant en congés jusqu'au 14. Nous verrons, donc...

Arrive le 15. La réunion rassemble le correspondant MOA en question, le responsable de l'hébergement du futur produit, différents intervenants dont les services sont concernés par le futur projet, Jean, et moi. Nous sommes en tout une petite dizaine. Hormis Jean et moi, tous sont des employés de GrosClient ou des prestataires longue durée agissant en son nom.

La réunion se passe plutôt bien pour ce qui nous concerne, la qualité de notre travail n'est pas remise en question. Nous observons par contre quelques désaccords entre les différents intervenants. Le responsable informatique explique notamment que pour ce type de projets, GrosClient n'utilise que certains logiciels dont la liste doit figurer au cahier des charges de l'appel d'offres. Ceux qu'il cite sont terriblement lourds et me semblent disproportionnés au vu de la prestation envisagée. Cela ne s'arrête pas là : certains points techniques doivent également être revus car non conformes aux normes internes de GrosClient ; ces normes doivent en outre être annexées au cahier des charges. Le reponsable informatique regrette enfin de ne pas avoir été impliqué plus tôt dans cette démarche. D'autres intervenants lui emboîtent le pas, et contestent le brief qui a été remis à Pascal pour servir de base à notre prestation. Cette fois, il ne s'agit plus de considérations techniques mais de considérations métier.

Jean et moi adoptons une attitude prudente et silencieuse. Nous avons bien envie de sourire, mais tacitement, nous décidons que ce n'est pas le moment.

Le responsable MOA nous questionne : certaines fonctions que nous avons défini sont complexes, bien que pertinentes à son sens. Peut-être devrait on prévoir un découpage en plusieurs lots de complexité croissante, si cela est possible ? Pour tenir compte de la remarque concernant les logiciels et formulée par le responsable informatique, peut-être pourrait on, en plus de lister ces produits, expliciter les conditions d'achat de leurs licences, en indiquant que les licences de développement - d'un coût substantiel pour certaines : de l'ordre de 50 ou 100 000 euros, de mémoire - sont à la charge du prestataire tandis que les licences de production - d'un ordre encore supérieur - sont à la charge de GrosClient ?

Nous prenons acte et bonne note. La réunion se poursuit, toujours sur fond de divergences internes, puis se termine.

Une fois seuls, Jean et moi échangeons nos sentiments sur cette affaire : nous ne la sentons pas. Nous nous attendons soit à recevoir dans quelques semaines un nouveau brief, soit à ne plus en entendre parler, GrosClient choisissant finalement de rédiger son appel d'offres seul, connaissant mieux que nous ses propres contraintes. Quant à répondre à cet appel, l'ampleur nouvelle donnée à la prestation par les contraintes techniques rend la chose impossible. Le prix des licences des logiciels que nous n'avons pas est rhédibitoire à lui tout seul.

Les semaines puis les mois passent, nous ne recevons rien. Pascal relance régulièrement le client, et obtient chaque fois la même réponse : c'est en discussion interne. Nous finissons par recevoir le paiement de notre prestation, puis Pascal cesse de relancer, n'espérant plus de suite à cette affaire.

L'année suivante, j'ai une nouvelle prestation à effectuer pour GrosClient. Je rencontre à cette fin le responsable informatique concerné, et le hasard veut qu'il s'agisse de celui intervenu lors de la réunion au sujet des logiciels et des flux de données.
« Vous vous souvenez de cette affaire, me lance-t-il. Savez vous ce que l'on a fait finalement ?
- Non, et en vous voyant, je me le demandais justement. Dites moi ?
- Un lot de 25 pages HTML statiques... Plus d'appel d'offres, on a tout géré en interne. »

Notre prestation d'appel d'offre, à elle seule, à dû coûter dix fois le prix de ce qui a finalement été réalisé...

Notes
[1]Les prénoms ont été modifiés.
[2]Ou du moins s'admet.

L'étiquette

2009-10-17T17:52:00.009+02:00

C'était ce matin, au supermarché du coin.

En panne de café, j'entreprends une recherche méthodique dans le rayon^[1] lorsque j'entends une voix me demander : « Pouvez vous me lire ce prix s'il vous plaît ? ».

C'est une dame, probablement d'une soixantaine d'années. L'étiquette qu'elle cherche à lire est une étiquette éléctronique, située à hauteur de genou. J'acquiesce évidemment, et donne l'indication après m'être plié en deux pour la lire.

Histoire d'être agréable, j'ajoute : « C'est vrai que ce n'est pas très pratique...
- Quand on est vieux ? Ah ça non !
- Ce n'est pas ce que j'ai dit !
- Mais c'est ce que je pense ! »

Elle sourit, amusée. Moi aussi.
« Bonne journée ! ».

C'est tout bête, mais c'est sympa. Le quotidien comporte son lot de petites rudesses, surtout dans les endroits bondés. Ces tout petits riens sont comme autant de pauses.

Notes
[1]Recherche d'autant plus méthodique que j'ai tendance à ne pas voir ce qui est situé juste sous mon nez, dans un supermarché, un réfrigérateur ou sur un bureau...

Mentions légales

2009-10-17T10:34:00.017+02:00

Ce journal est un service de communication au public en ligne édité à titre non professionnel au sens de l'article 6, III, 2° de la loi 2004-575 du 21 juin 2004. Conformément aux dispositions de cet article, son éditeur a choisi de rester anonyme^[1].

Ce journal est accessible à tous. La possibilité de commenter les articles publiés sur ce journal est ouverte à tous les visiteurs, dans les limites du respect, de la courtoisie, et de la liberté d'expression telles qu'admises par la loi française. A des fins de modération, l'éditeur se réserve le droit de supprimer tout ou partie des commentaires publiés, sans justification ni information préalable.

Les billets de ce journal ainsi que leurs commentaires sont mis à votre disposition sous un contrat Creative Commons. Vous êtes libre de reproduire tout ou partie de ces contenus à l'identique et à des fins non commerciales. Vous devez simplement citer leurs auteurs.

L'hébergeur de ce journal est Google Blogger. Conformément à la loi, mes éléments d'identification personnelle lui ont été communiqués.

En cas de réclamation sur le contenu de ce site, commentaire ou billet, je vous propose de m'adresser un courrier électronique à l'adresse sofienne.rida@yahoo.fr.

La loi vous permet de vous adresser directement à l'hébergeur. Il met pour ce faire cette page à votre disposition. Vous pouvez également écrire à
Google Inc.
1600 Amphitheatre Parkway
Mountain View CA 94043 (États-Unis)

Sachez alors que l'article 6, I, 4° de la loi 2004-575 du 21 juin 2004 stipule : "Le fait, pour toute personne, de présenter aux[hébergeurs du site] un contenu ou une activité comme étant illicite dans le but d'en obtenir le retrait ou d'en faire cesser la diffusion, alors qu'elle sait cette information inexacte, est puni d'une peine d'un an d'emprisonnement et de 15 000 EUR d'amende."

Enfin, en accord avec les conditions d'utilisation des services Google, soyez informé que ce site utilise Google Analytics, un service d'analyse de site internet fourni par Google Inc. (« Google »). Google Analytics utilise des cookies , qui sont des fichiers texte placés sur votre ordinateur, pour aider le site internet à analyser l'utilisation du site par ses utilisateurs. Les données générées par les cookies concernant votre utilisation du site (y compris votre adresse IP) seront transmises et stockées par Google sur des serveurs situés aux Etats-Unis. Google utilisera cette information dans le but d'évaluer votre utilisation du site, de compiler des rapports sur l'activité du site à destination de son éditeur et de fournir d'autres services relatifs à l'activité du site et à l'utilisation d'Internet. Google est susceptible de communiquer ces données à des tiers en cas d'obligation légale ou lorsque ces tiers traitent ces données pour le compte de Google, y compris notamment l'éditeur de ce site. Google ne recoupera pas votre adresse IP avec toute autre donnée détenue par Google. Vous pouvez désactiver l'utilisation de cookies en sélectionnant les paramètres appropriés de votre navigateur. Cependant, une telle désactivation pourrait empêcher l'utilisation de certaines fonctionnalités de ce site. En utilisant ce site internet, vous consentez expressément au traitement de vos données nominatives par Google dans les conditions et pour les finalités décrites ci-dessus.

Notes
[1]Sofienne Rida est un pseudonyme.