En l’absence totale de confiance, il faut la foi. J’ai foi dans ce pays.

Cette histoire commence quand j’ai présenté ma démission au Président. Qu’il a refusée. M’a dit de réfléchir et que ma démission affaiblirait le gouvernement. Ce fût le mot juste pour me convaincre, car je ne voulais absolument pas que ma démission soit interprétée comme un soutien à ceux qui veulent la chute du gouvernement.

Quand j’ai vu la foule demander la chute du gouvernement, j’ai pensé à cette formule inventée par un ami à l’occasion de la démission de Ghanouchi “le gouvernement Sisyphe”. Condamné à un éternel recommencement. Et j’ai vu les élections s’éloigner. C’était ça la raison de ma démission.

Ma liberté d’expression

L’une de mes premières surprises au sein du gouvernement ce fut le fait que je sois devenu moins libre de m’exprimer. Du côté du gouvernement j’avais carte blanche, mais du coté du peuple je ne l’avais plus. Je devais le respect a mes concitoyens, même les plus cons. Je ne pouvais plus exprimer mes théories du complot qui me tenaient à coeur et qui constituaient mes croyances personnelles, j’avais des responsabilités.

Je vais vous dire comment la gouvernement m’a endoctriné.

Dés le premier jour j’ai été accueilli avec une manif. Et jusqu’a aujourd’hui j’ai tous les jours des manifs/sit ins/grèves à mon ministère. Bien sûr les gens qui manifestent ne sont pas les mêmes, ils vont, ils viennent, ils ont différentes revendications. Mais l’essentiel de mon travail depuis les premiers jours à été d’écouter ces revendications et d’essayer d’expliquer que nous n’allons pas résoudre les problèmes. Nous allons faire des éléctions.

Toute la difficulté est là. Pour faire des éléctions il ne suffit pas de mettre en place des bureaux de vote, il faut mettre le contexte, il faut que le climat soit sain. Il ne faut pas qu’on vote alors qu’on est stressés ou qu’on a peur. Il faut qu’on vote en pleine conscience et en toute liberté. Et pour ça il faut résoudre les problèmes.

Comment se passe le travail au gouvernement?

Si vous avez déjà travaillé en équipe, vous le savez déjà. Le gouvernement est un groupe,  on se réunit régulièrement pour discuter principalement de projets de décrets et de la situation du pays a partir de notes des membres. La dynamique de groupe c’est les relations humaines. On se parle. Et chaque membre du gouvernement est chargé de trouver des solutions  dans son domaine. Mais chaque ministre ou secrétaire d’état, comme moi, est confronté à la même réalité : on ne peux pas résoudre les problèmes.

Parce qu’on est un gouvernement transitoire et qu’on ne peux pas engager le pays au delà de quelques mois.

J’ai vu très tôt le problème majeur que présente le Ministère de l’intérieur. Ce Ministère représente la force publique. Et ce Ministère fut corrompu pendant des annèes au moins autant que mon Ministère. Il a pratiqué la repression et la torture pendant des annèes. Et si il y a un ministère qui doit changer maintenant c’est bien celui là. Ce ministère a besoin de réformes profondes dans les pratiques de ses employés parce que chaque employé devra être exemplaire quelque soit le résultat des élections et quelque soit sa direction. J’en ai parlé au Min. Intérieur. Mais ce n’est pas simple.

M. Le Ministre de l’intérieur est de bonne volonté. Il est là dans le but de servir le pays. Et tous les membres du gouvernement le sont. Je peux en attester, du moins par le peux d’occasions ou j’ai eu a les côtoyer dans ce laps de temps au demeurant très court. Ce sont des relations humaines.

Quand je suis entré au gouvernement c’est pour ces relations humaines essentiellement. Tout est relations humaines. Je voulais connaitre ces gens personnellement. Accèder à ce réseau social, je disais. Pour batir la confiance. Et maintenant c’est fait. J’ai confiance. C’est comme ça que j’ai été endoctriné.

Vous me direz on ne peux pas avoir confiance en 4 mois. Ça dépend. J’ai confiance en ce gouvernement pour organiser des élections libres et c’est tout ce dont j’ai besoin.

Vous vous rappelez de la vidéo de wikileaks qui montrait des soldats américains en train de tuer des civils qui marchaient dans la rue?

Cette vidéo avait déclenché une petite conversation avec quelques amis sur twitter autour du thème de la responsabilité et les systèmes d’armes. En gros @alaa disait que les talibans avec leurs Kalashnikov avaient un plus grand sens moral que ces jeunes cons que sont les soldats américains (se référant aux voix des soldats et à la manière avec laquelle ils s’amusaient visiblement a tuer des gens). @jiliancyork disait que la guerre avec les systèmes d’arme modernes ressemble a un jeu video et que ces jeunes soldats ne se rendaient même pas compte de la gravité de leurs actes. J’étais d’accord avec @alaa, avec une Kalachinkov comme outil de meurtre on devient forcément plus moral. Où alors on meurs très vite. Quand tous tes sens sont confrontés à la présence de la victime, même pendant quelques secondes, c’est autrement plus impliquant que des images en noir et blanc sur un petit ecran. Il est notoire qu’un outil te change l’homme.

Mais contrairement à @alaa, je maintenais qu’il est possible de concevoir les systèmes d’armes modernes de façon à garder la responsabilité proche du tueur. Et qu‘il est possible de concevoir la procédure de sélection de soldats de façon à la lier à leurs degré de responsabilité et à leurs aptitudes décisionnelles. Ce qui aura pour effet de diminuer ce genre de meurtres. Il n’est pas obligé que le système soit basé sur la mort au combat des soldats les moins aptes, le cas des Talibans. Un soldat pourrait tout simplement être responsable, juridiquement, de ses meurtres. Je rappelle que les soldat américains en question n’ont pas été inquiétés et que leurs responsabilité n’a nullement été engagée. Et que ceci est du directement au système d’endoctrinement de l’armée conventionnelle qui est spécifiquement basé sur la déresponsabilisation des recrues et sur la dilution de la prise de décision. Ce qui n’est pas le cas dans la guerrilla talibane.

Voyons si on peut concevoir un système décisionnel qui distribue correctement la responsabilité pour les armées.

La responsabilité est basée sur l’engagement. Ça consiste en une déclaration Publique sur une Action future. Une promesse publique. C’est une sorte de prêt sur l’Autorité : l’engagement donne un surplus immédiat d’autorité, mais la réalisation de l’action liée à l’engagement donne encore plus d’autorité. L’autorité reflète la valeur d’un homme dans la société. C’est une valeur directement liée au degré de confiance accordée à cet homme dans une société. Pour un soldat, comme pour tout homme, avoir très peu d’autorité dans sa société (l’armée) devrait constituer un motif d’éviction.

Dans une société ou la Confiance est basée sur les historiques publics (ex. Internet) cela ressemblerait a une timeline ou au 15 décembre 2009 vous dites « j’arrête de fumer le 1er janvier 2010″ et au 1er janvier 2010 vous dites « J’ai arrêté de fumer ». C’est vôtre engagement le 15 décembre qui constitue vôtre responsabilité. Ne pas réaliser vôtre engagement vous coûterait une pénalité d’autorité vis a vis de vos proches.

Un tel dispositif est peux être nécessaire pour l’armée vu le nombre de soldats. Mais cela dépend de la structure des unités et de la fluidité de la circulation de l’information entre les différents acteurs entrant dans la prise de décision. Des petites unités autonomes avec une structure en openspace, informelle, à la Talibane permettrais de faire à moins de ce dispositif informatique.

Mais le défaut central dans la procédure de l’armée est clair : celui qui appuie sur la gachette n’est pas le seul a prendre la décision de tuer. Il demande a ses supérieurs. C’est cette distance délibérément introduite entre le soldat et la responsabilité qui est à l’origine du problème. Ce problème doit être résolu procéduralement avec deux dispositions : un engagement du soldat a ne pas tuer de civils et l’exclusion de toute implication autre que celle du soldat dans le meurtre.

Pour rapprocher encore plus le soldat de sa responsabilité, un surplus d’information n’est pas du luxe. Les technologies sensorielles sont d’ores et déjà disponibles et non encore suffisamment utilisées à l’armée.

Pour l’armée il faudrait donc :

• Un engagement formel de la part des soldats de ne pas tuer des civils (un contrat d’engagement)
• Une infrastructure de confiance basée sur les historiques publics. En d’autres termes un Facebook pour l’armée.
• Un autonomie complète sur le meurtre. Le soldat ne demande jamais l’autorisation de tuer et le commandement ne donne jamais l’ordre de tuer. C’est taboo. Un peu comme la police.
• Un armement plus performant : vision 3D, micro directionnel avec écoute surround.

La mauvaise décision a toujours comme origine un manque d’information. Dans les systèmes d’information que nous construisons, quand un utilisateur se trompe, le client nous demande systématiquement de restreindre sa liberté d’action, ce qu’on fait souvent c’est lui donner plus d’information et comme par miracle il ne se trompe plus.

@alaa a fini par dire que les américains n’en avaient rien a foutre de tuer les civils, ce qui les intéresse c’est de vendre des armes. Ce à quoi j’ai rétorqué que effectivement tuer des civils ne les intéresse absolument pas, ce qui les intéresse c’est de vendre les armes le plus cher possible à leurs contribuables. Et par conséquent un système d’arme qui permet de tuer moins de civils et qui coûte très cher devrait allécher leurs fabricants d’armement. Il y a donc un espoir.

D’ailleurs au cas ou quelqu’un du DOD est à l’écoute, j’offre nos services de consultants en systèmes d’information web. Notre facture sera à la hauteur de vos ambitions.

Sinon, donnez a Wikileaks

Vôtre Attention vaut de l’argent. C’est encore plus flagrant dans la publicité. Quand vous regardez un film à la TV et que ce film est entrecoupé par de la publicité, les gens qui ont fait le film en question sont payés par l’argent de la pub qui entrecoupe leur film.

Avec ma femme on se dispute quelques fois. A vrai dire c’est elle qui me dispute. Toujours pour les mêmes raisons :

• Je devais laver la vaisselle et je ne l’ai pas fait
• Je devais changer une ampoule et je ne l’ai pas fait
• Je devais réparer un meuble et je ne l’ai pas fait
• Je devais sortir la poubelle et je ne l’ai pas fait
• Etc…

On peut voir clairement un motif apparaitre ici. C’est toujours quelque chose qu’elle me demande de faire, quelques fois implicitement i.e. « c’est pas la peine que je te dise, c’est à toi de le faire », et que je ne fais pas. Et elle s’énerve. Si vous êtes un homme, vous devez savoir que toutes ces choses que je suis sensé ne pas avoir faites, j’allais les faire… mais pas tout de suite. Mais ma femme ne comprend pas ça. Elle trouve que mettre 1 mois pour réparer une ampoule c’est trop.

Je sais. Parfois j’abuse. Mais il faut me comprendre. J’aime pas que ma femme me donne des ordres. Je trouve cela très désagréable. Mais vous me connaissez bien maintenant, j’ai bien sûr une explication rationnelle à ça aussi.

Voyez vous, cela ne me dérange absolument pas que ma femme m’ordonne de faire telle ou telle chose. Ce qui me dérange c’est quand elle me dit de le faire maintenant. Interrompant ainsi mon activité courante. C’est cette obligation de porter mon Attention sur ce qu’elle veut elle, qui me procure cette sensation désagréable… d’être un esclave. Ou une machine. Un objet sans Autonomie. Ce que ma Conscience rejette catégoriquement. Mais ma conscience est tout à fait prête a faire des concessions si on me paie.

Il se trouve que je suis particulièrement conscient de la Valeur de mon Attention parce que de par mon métier de consultant, je vend mon Attention tous les jours à l’heure. Il est important de comprendre ici que ce que je vend ce n’est pas mon Activité ou le résultat de mon activité – que ce soit un rapport ou un programme informatique. La preuve c’est que certains clients me paient uniquement pour être Disponible pour eux. C’est à dire pour ne rien faire (et attendre leurs ordres). Dans tous les métiers de l’économie dite « Immatérielle », et beaucoup de métiers de service, la marchandise c’est l’Attention. Les Avocats, les agence de communication, les psychanalystes… vous pouvez aisément reconnaitre ces métiers aux conflits récurrents concernant la « non obligation de résultat« . Quand vous faites du support, informatique ou autre, le client vous paye pour répondre au téléphone au cas ou il appelle. Notez que s’il n’appelle pas, il est paradoxalement encore plus satisfait parce que cela voudrait dire qu’il n’a aucun problème. Ou du moins il devrait l’être, mais la « non obligation de résultat » a toujours du mal à passer. Et c’est principalement dû à l’ignorance de l’économie de l’Attention.

Vôtre Attention vaut de l’argent. C’est encore plus flagrant dans la publicité. Quand vous regardez un film à la TV et que ce film est entrecoupé par de la publicité, les gens qui ont fait le film en question sont payés par l’argent de la pub qui entrecoupe leur film. C’est plus compliqué que cela : les gens qui vendent un produit payent les gens qui ont une chaine TV pour placer leurs pub dans le film, par la suite les gens de la chaine TV paient les gens qui ont fait le film. Pourquoi les gens qui vendent un produit paient pour placer leur pub dans le film? Pour avoir vôtre Attention. L’Attention des gens qui regardent le film. Ici mon esprit d’analyste-programmeur-optimisateur ne peut souffrir une telle aberration et ne peut s’empêcher de se demander : Pourquoi les gens qui vendent un produit ne paient pas directement les gens pour regarder leurs pub? Si 30s de pub vaut 300 000 dinars quand il y a 1 000 000 de personnes qui regardent, donc 1s de vôtre Attention vaut 0.010 dinars. Je sais pas vous, mais moi je regarderais bien de la pub pendant 150s (2min30s) pour gagner 1.5 dinars et aller m’acheter le film que je veux au vendeur de DVD de mon quartier.

Vous pouvez trouver cela coccace, mais moi je crois, j’ai la foi, que dans le futur on vous payera pour vôtre Attention. Y compris pour regarder de la pub ou pour participer a des évènements sponsorisés. Et comme d’habitude sur internet, c’est déjà demain.

Il y a de cela 6 mois, Jean-Michel Blanquer, recteur de l’académie de Créteil en France a décidé d’expérimenter une nouvelle approche qui consiste a rémunérer ses lycéens pour leur Attention. Il va sans dire que cela a déclenché un tollé général en France. Mais éxaminons la situation à l’aune de l’économie de l’Attention. L’Attention de ces jeunes gens a de la valeur. D’ailleurs l’Attention que renferme un être humain, lui donne une valeur pragmatique, non éthique, non idéologique, quelque soit son age, son sexe ou sa race. Ce qui est assez intéressant en soi. Ces jeunes gens sont donc éduqués obligatoirement par l’état français pour l’intérét de la France. Je souligne ici le bénéficiaire qui est la France. La motivation théorique de ces jeunes gens étant la perspective d’une embauche dans un emploi qualifié (par la susdite éducation). Or éloigner temporellement le bénéfice (l’embauche) de l’acte (la présence, qui est l’acte de l’attention) est une très mauvaise manière de motiver en général et particulièrement quand il s’agit d’adolescents.

Il n’y a pas à tourner autour du pôt. Pour une éducation éfficace, l’éducation nationale Française devra gèrer l’Attention des étudiants d’une manière ou d’une autre. Ayant un biais pour les solutions simples et pragmatiques, je trouve que rémunérer les étudiants pour leur Attention est une solution idéale. Ne serait ce que pour son accompagnement au changement de paradigme et son altérnative au revenu de vie.

Les 4 derniers jours de 2009 nous avons déployé notre progiciel de gestion intégré ALIX dans le dépôt principal de l’un des grossistes majeurs en pharmaceutiques en Tunisie. C’est une opération pour laquelle nous nous sommes préparés toute notre vie… Ou presque, étant donné qu’au décompte final le projet a duré 3 ans et demi. Pour aboutir a ce déploiement qui consacre ALIX comme seul système d’information dans toute l’entreprise et sonne le glas de tous les autres logiciels utilisés de la production au recouvrement.

Une semaine avant…

Je venais de rentrer de Beirut, et ce weekend nous avions un inventaire dans le petit dépôt du client. Le système ALIX était déjà en production depuis plus d’un an dans ce dépot, mais c’est toujours délicat un inventaire. Parce que justement c’est 1 fois l’an et que par conséquent on n’a pas souvent l’occasion de le tester en production. De plus, suite au dernier inventaire nous avons fait des modifications majeures sur le système et aux procédures; et c’était donc du code frais que nous allions utiliser.

Tout s’est bien passé. L’enjeu principal dans les inventaires, qui restent sommaires au niveau applicatif, c’est le temps. Ce jour là nous avions fini plus tôt que prévu. Ce qui nous réconfortait dans nos choix et nous rassurait sur le plus important : le déploiement final dans le grand dépôt dont la date n’était toujours pas fixée mais qui était imminent.

Etant donné que nous avions fini tôt, M. Bechir qui supérvise le projet ALIX pour notre client, improvise une petite réunion. Il nous éxplique qu’il est satisfait et qu’il propose de déployer la semaine prochaine dans le grand dépot. Nous allons faire le déploiement dans les règles de l’art au début de l’année fiscale, ce qui avait l’avantage de limiter de façon radicale le risques de géstion liés au changement de système en cours d’annèe fiscale et d’intègration de données à partir de l’ancien système (forcément).

Avec Bechir et Hassen (l’équipe ALIXSYS, au cas ou vous seriez nouveau sur ce blog. Par ailleurs, ne pas confondre Bechir avec M. Bechir le client) nous avions déjà discuté de cette éventualité et avons conclu que nous étions préts. J’ai donc accépté.

Or rien n’était prêt. Les stations de travail et leurs périfériques qui devaient étre changés n’étaient pas inventoriées, le matériel n’était pas encore commandé, le chantier du réseau avait à peine commencé et il fallait encore des semaines pour qu’il se termine.

Heureusement qu’avec ce projet, j’avais appris quelque chose d’essentiel : le zen. Les choses se passent toujours mieux que prévu… si on se prépare pour le pire. Le truc c’est de ne pas essayer d’éviter le pire, il faut économiser ses éfforts pour être prêt quand le pire arrivera. J’ai donc proposé de déployer sur le réseau en place avec le matériel en place. Le raisonnement était qu’il est trop tard pour organiser quoi que ce soit qui implique une étude ou ne serait ce qu’une simple réflexion : nous allions mettre en place le matériel essentiel, c’est a dire les 2 imprimantes industrielles et stocker des stations de travail et des périphériques de rechange prêts a être déployés dés qu’il y a un problème matériel quelque part dans le dépôt.

Makram, le responsable informatique du client, n’était pas d’accord. Il n’y avait rien à faire pour le réseau, mais pour le côté matériel il estimait qu’il était possible d’inventorier les machines dépassées, les remplacer et switcher toutes les stations de travail sous Linux la nuit de l’inventaire. Et comme tout ce volet est sous sa responsabilité, il avait le véto. Nous allons donc faire comme il dit. Et nous allons voir qu’il avait raison.

La semaine suivante je l’ai passée a préparer 3 checklists : 1 pour l’inventaire, 1 pour le déploiement et 1 timeline. Ce travail a consisté a tester le système pour les cas d’utilisation de l’inventaire et du déploiement et faire une liste des points a vérifier et les taches a faire pour que tout se passe bien. Ensuite ces points sont discutés avec Hassen et Bechir qui enrichissent la liste avec leurs remarques. Nous avons fait cela tous les jours pendant toute la semaine. La timeline était subdivisée en 4 jours et etait mise a jour au fur et a mesure avec les taches qui devaient se faire un jour précis. Bechir et Hassen s’occupaient de régler les problèmes qui pouvaient être réglés tout de suite : certains détails de la procédure de déploiement pouvaient être réglés par des changements sur les application, notamment l’application d’intégration de données avec les anciens logiciels. A vrai dire il y a des défauts que nous avons découvert à ce moment là et qu’il fallait régler aussi.

1 pour le déploiement, 1 pour l'inventaire et 1 timeline

Week-end de l’inventaire : problèmes d’intégration de données

L’inventaire devait se faire le week-end, comme tous les ans, pour ne pas impacter la production. Le vendredi nous avons commencé a préparer le système, y compris les personnes en leurs donnant les instructions nécessaires. Les procédures d’inventaire se basaient principalement sur du papier mais avaient significativement changé et impliquaient maintenant plusieurs utilisateurs du système dans la saisie et le contrôle du déroulement en temps réel.  Nous avons fait en sorte que l’encadrement des utilisateurs soit fait par le personnel de l’entreprise qui est déjà formé. Le but étant qu’on soit disponible en cas de problème. On ne ferait donc rien. Et ça sera très bien comme ça. Et nous n’allons pas tarder a confirmer l’utilité de cette approche.

L’inventaire commence par le décompte des quantités physiques des articles en stock et se finit par leurs comparaison avec les quantités informatiques (prévues). Pour pouvoir commencer le décompte le plus tôt possible (lundi matin étant une date butoir : reprise d’activité) , nous avons choisi de faire une intégration des données en deux étapes. Nous allions intégrer les données des articles a partir de l’ancien logiciel de stock vendredi soir (ils ne risquaient pas de changer) et les données de l’état des stock samedi quand il n’y aurait plus d’activité dans le dépôt.

Samedi matin on vient, on fait rien, aucun problème. Samedi après midi, on intègre les données de l’état des stock et BANG! Nos états de vérification nous disent que les données intégrées ne correspondent pas aux informations données par l’ancien système. On a bien fait de rester disponibles. On a bien pensé que le bug serait facile a trouver au début,… à 1h du matin on était encore au bureau. Et vous savez le PC DOS virtualisé qu’on avait mis en place il y a presque 1 an pour convertir les listings de l’ancienne application? Eh bien, il nous a encore sauvé la vie. Après inspection minutieuse, il y avait au moins une dizaine de différences de plusieurs types dans les articles. Tous des problèmes d’intégration, aucun bug, et parfois des erreurs de jugement : dans le paragraphe précédent j’ai dit « ils ne risquaient pas de changer », eh bien ils ont changé les prix des articles.

Le dimanche matin, nous étions là. L’état du stock informatique intégré a partir de l’ancienne application était conforme et vérifié. Tout allait bien. Dans ma timeline, je vois : « dimanche : Installer le matériel de déploiement ». Étant donné que Makram avait décidé de switcher toutes les stations de travail à Linux, ça allait être le grand soir. L’après midi l’inventaire était bouclé sans incidents, ce qui représentait un temps légèrement inférieur aux inventaires pratiqués avec l’ancien système. Les utilisateurs directs et indirects étaient satisfaits. Le soir nous étions très fatigués nous sommes arrivés a installer tout le matériel, a convertir presque toutes les stations de travail à Linux et les configurer pour qu’ils se connectent sur l’application web ALIX. A vrai dire Makram et Hassen on fait presque tout le boulot. Nous avons désigné Bechir pour venir le lendemain a 6h du matin pour le déploiement : c’est à cette heure là que commence l’activité. Il fallait que quelqu’un se dévoue.

Bechir est capable d'analyser l'output d'une requête SQL en temps réel. Comme dans Matrix.

Premier jour d’utilisation : 1 processus et 2 interfaces utilisateur changées à chaud

Le 1er utilisateur du système fut M. Hmida, opérateur du centre d’appel qui commence sa journée à 6h du matin. Quand il a débarqué le paysage du dépôt avait complètement changé, sur sa station de travail aussi. Bechir était là pour le rassurer. Le premières commandes furent livrées sous la surveillance de Bechir, et en toute sérénité. C’est vers 9h quand tout le monde a débarqué, y compris Hassen et moi même, que les choses ont commencé a se corser.

Le serveur a commencé a échouer la baleine (en argot geek, ça veut dire avoir des problèmes de surcharge. voir Fail the whale). Le système était a la limite de l’inutilisable. C’était le bordel. Les commandes partaient en retard, le contrôle qualité était fait à l’emporte pièce. C’était le bordel.  Ça nous a pris 1 heure pour diagnostiquer le problème : 1 tableau de bord utilisé par ~50% des utilisateurs, notamment par les contrôleurs qualité,  bouffait les ressources comme pas possible. Réunion de crise : mesure d’urgence : rallonger le temps de rafraichissement des indicateurs. Ensuite discussion :

1. Cette interface est irrécupérable. Elle doit afficher les commandes en cours avec leurs états en temps réel. Autant dire toute l’activité du dépôt. Elle traite énormément de données et on aura beau optimiser, on ne gagnera pas beaucoup et ça prendra du temps.
2. Cette interface est utilisée par deux rôles dans le système : les contrôleurs qualité (en large majorité) et 8 magasiniers
3. Les contrôleurs qualité (CQ) n’utilisent en fait qu’une seule fonctionnalité de l’interface et qui ne consomme pratiquement aucune ressource

En 15 minutes nous avons fait une nouvelle interface pour l’armée des CQ, en 15 minutes nous l’avons testée, en 15 minutes nous l’avons déployée, en 30 minutes nous les avons formés. Ce sont les joies du MVC et de l’architecture RESTful. Ce fût une réussite : la charge du serveur est tombée de moitié. Les CQ ont même préféré cette interface, évidemment : elle est plus simple.

Si nous avons pu faire cette interface aussi rapidement, c’est qu’elle fait partie d’une catégorie de tâche que nous avons classée dans notre wiki dans : « Les tâches que nous n’aurons jamais le temps de faire ». Nous avions bien identifié un problème d’ergonomie dans cette interface (les CQ n’utilisaient que 0.1% de cette interface), nous avions bien discuté et trouvé une solution élégante, mais rien ne justifiait de leurs faire une interface propre jusqu’à maintenant. Parce que l’ergonomie n’est pas une science exacte et :

• Nous n’avions reçu aucun feedback négatif de la part des utilisateurs (testeurs)
• Du point de vue de l’expérience utilisateur, plus il y a d’utilisateurs qui utilisent une interface, mieux c’est. Ils s’entre-aident. C’est l’effet communauté. C’est pour cela que je pense, par exemple, que les interfaces personnalisées sont généralement mauvaises du point de vue de l’expérience utilisateur.

Hassen en vitesse de croisière

Changer les procédures au nez et à la barbe de ISO9001

Le système était redevenu utilisable, d’autant plus que l’heure de pointe pour l’activité est passée. Tout allait bien, ou presque… Malgré le fait que ALIX fonctionnait bien, les commandes continuaient à prendre un léger retard. A première vue, ça bloquait au niveau de la préparation des commandes. Une petite inspection sur place pour prendre le pouls des utilisateurs, à permis très vite d’identifier le problème. La procédure était trop lourde et les commandes s’accumulaient au milieu du magasin.

Par rapport au petit dépôt sur lequel ALIX s’était fait les dents, ce dépôt si est énorme. Il est subdivisé en 8 zones, dont 3 sont contiguës et numérotées 1,2,3.  La procédure imposait une validation au début et a la fin de chaque zone. Mais voilà, le zones 2 et 3 étaient dépendantes de la zone 1 : on ne pouvait commencer la zone 2 qu’après avoir fini la zone 1. Ce qui fait que dépendamment des commandes, le magasinier  de la zone 2 pouvait terminer une commande et revenir au début de sa zone pour se retrouver avec 5 commandes en attente et d’autres qui arrivent (ça peut prendre beaucoup de place). Ce qui ajoute a la confusion c’est qu’il doit aussi gérer se propres priorités et renseigner le système. Ce n’était clairement pas faisable. Et les commandes s’accumulaient en zone 2.

Ce qui est incroyable c’est que cette procédure était en place depuis des années et était même documentée et certifiée ISO9001, mais l’ancien système de gestion de flux – développé par nous mêmes d’ailleurs. Une ancienne version de ALIX – permettait de la contourner. Ils validaient toutes les zones qui restent à la fin de la journée!!

Réunion de crise : mesure d’urgence : faire sauter la zone 2. Après avoir discuté des conséquences possibles, nous avons simplement dit au magasinier de la zone 2 d’ignorer le système et de faire juste son travail de préparation des commandes. Ensuite nous avons fait sauter quelques verrous par ci, par là, et nous avons entrepris de changer l’interface des magasiniers pour que ces trois zones se comportent comme une seule zone dans certains cas. Et tant pis pour ISO90001, il suivra. Cette dernière tâche prendra le reste de la journée et le lendemain matin.

La magie

Le lendemain la magie à opéré. Malgré le fait que le serveur continuait a faire des pics de charge a 10 (normalement le maximum c’est 1) tout marchait, les utilisateurs – bizarrement – ne se plaignaient pas, et les commandes étaient traitées au rythme normal comme si de rien n’était. Nous n’en revenions pas. On est restés sur nos gardes toute la journée, mais rien.

Bien sûr, il y avait encore plein de choses à faire, une longue liste de défauts a corriger, des fonctionnalités a ajouter, mais il n’y avait plus le bordel. Il faut comprendre que le plus grand défi dans un projet qui implique autant de personnes est logistique et organisationnel. Si la sauce ne prend pas, vous aurez beau faire, le projet sera un échec. Le utilisateurs sont inter-connectés procéduralement, si une partie refuse d’utiliser le système parce qu’elle estime qu’il est inutilisable, vous n’aurez pas le temps de corriger le problème avant qu’une autre partie n’arrête de l’utiliser parce que son utilisation du système dépend de la première.

J’avais planifié 2 jours de bordel, et ça s’est résolu en 1 jour. J’estime que c’est un succès notable. Mais pour rendre a césar ce qui appartient à césar, ce succès n’est pas le nôtre, c’est celui de l’entreprise qui a commandé le projet avec tous ses employés et ses gestionnaires que je tiens a remercier particulièrement. A vrai dire mon impression est que toutes les conditions du succès étaient là avant qu’on arrive.

Ou j’explique que la discrimination est le seul mécanisme par lequel on crée de l’identité.

Les Collections sont des Objets fascinants. Supposons que vous soyez un collectionneur. De timbres. Vous ouvrez l’un de vos grands album, comme d’habitude, pour profiter du réconfort de la vision de vos timbres et souvenirs associés; bien rangés dans leurs pochettes. Mais voilà que cette foi, au beau milieu de l’album, vous trouvez une image autocallante panini. Vous vous en offusquez : Qu’est ce que cette image fait là?

Mais pourquoi est ce que vous pensez que cette image n’est pas a sa place, d’abord? Parce que ce n’est pas un timbre? Comment vous le savez? Il y a bien des timbres à l’éffigie de joueurs de foot, il y a bien des timbres autocollants, il y a bien des timbres de cette taille là, il y a bien des timbres sans dents. Qu’est ce qui fait que l’image autocollante est différente? Et surtout qu’est ce qui fait que les timbres sont Identiques? C’est fascinant une collection. Parce que tous les objets qui y appartiennent sont identiques; d’une certaine manière. Et en même temps, évidemment, différents.

En réalité pour Discriminer la simple image autocollante des timbres; vous vous référez probablement a différents Signes imprimés sur les timbres qui indiquent qu’une Autorité postale garanti leurs Authenticité.

Résumons :

• Une collection c’est fait d’objets à la fois identiques et différents, un peu comme les Hommes
• Si vous voulez identifier un ou plusieurs objets de la collection pour les exclure ou pour les classer dans une autre collection, ça revient a les discriminer des autres objets de la collection. En somme Identifier = Discriminer.
• Quand il est impossible de discriminer – ce qui est courant vu la dichotomie Identité-Différence au sein d’une collection – on fait appel a une Autorité qui tranche arbitrairement.

Un modèle de société avec la personne en haut et la société en bas

Maintenant, j’ai 13 ans. Je construit mon Identité avec ce qui me tombe sous la main : musique, série télévisée, équipe de foot, religion, jeux vidéo, voir même quelques fois mes parents. C’est que je suis un être humain doué de conscience et que le mécansime d’identité est cablé dans mon cerveau par 3 000 000 d’années d’évolution. Ce n’est pas par hasard que l’évolution a séléctionné ce comportement : l’identité est le socle de la confiance et la confiance le socle de la société. Je ne peux pas faire confiance à quelqu’un que je ne reconnais pas. Par ce qu’il m’est impossible de me rappeler ce qu’il a fait dans sa vie (son Historique), ou qui est la personne qui me l’a fait connaitre (son Autorité supérieure). L’historique et la délégation d’autorité sont les deux uniques mécanismes pour bâtir la confiance.

Pour vivre en société je dois pouvoir Identifier les membres de ma société et leurs permettre de m’identifier. Pour cela j’utilise la discrimination : je commence par me discriminer moi même, construire mon Identité, ceux a qui je veux ressembler, j’émule. J’utilise les Signes.  Je porte un jean tombant, je suis un cholo. Je met du Khol, je suis un emo. Ensuite je discrimine tous ceux qui me ressemblent de ceux qui ne me ressemblent pas et je crée avec eux des liens d’Autorité. C’est cela une société.

Résumons:

• Construire son identité c’est se discriminer soi même.
• La fonction de l’identité dans une société c’est de permettre la confiance en assurant la reconaissance.

La France connait en ce moment un grand débat sur l’identité nationale. Mais que signifie Identité nationale? Est ce que cela a un sens? On pourrait imaginer ce modèle : Une société des nations (ou une collection de nations). Pour construire l’identité nationale, il faudrait discriminer sa nation des autres nations. Mais sur quels critères? On pourrait choisir quelques valeurs : liberté, égalité, fraternité. Ou alors instaurer une Autorité qui discrimine arbitrairement. C’est aux français de voir. L’identité nationale a donc bien un sens.

Il doit vous surprendre que la question de l’immigration n’a aucune relation proche ou lointaine avec le sujet. J’en suis surpris moi même. Il est évident qu’en créant un ministère de l’immigration et de l’identité nationale (entre autres), la France ne se facilite pas la tâche. Cela ne fait que brouiller les pistes et ajouter à la confusion. Logiquement l’identité nationale devrait être du ressort du ministère des affaires étrangères. Si on opte pour la solution de l’autorité de discrimination, bien sûr…

• En 2024 je voterais pour X. Et je poserais une seule condition à ce X : qu’il ne soit pas de la famille proche ou lointaine ou par alliance du président actuel Zine El Abidine Ben Ali.
• Je m’engage à répertorier comme je peux, sur internet, les personnes aptes à devenir président de la république Tunisienne.
• Je m’engage à me rendre disponible autant que je peux pour discuter de ces idées au prés des membres sérieux du RCD.

Ce qui est sûr, c’est que nous aurons un nouveau président en Tunisie en 2024. Il est possible que nous en ayons un avant, mais en 2024 c’est sûr. J’apprécie énormément le travail, la ténacité et les sacrifices que font tous ceux qui veulent un changement maintenant. Mais à mon grand désespoir, mon cerveau est cablé de telle manière que je ne peux pas répéter la même chose des milliers de fois jusqu’à ce que ça rentre dans la tête des gens, je ne suis pas tenace et je ne tiens pas tête à l’adversité naturellement.

Il faut savoir que je gère des projets pour vivre, et en cette qualité je sais que pour atteindre un objectif non trivial, c’est à dire pour un projet qui dûre plus que quelques semaines, il y a deux types de temporalité : l’immédiateté et la prospective. Il y avait donc bien un rôle pour moi dans ce projet commun. Alors je me suis dit que j’allais aider comme je pouvais : je vais m’occuper à préparer les présidentielles de 2024. Pour assurer les arrières.

• En 2024 je voterais pour X. Et je poserais une seule condition à ce X : qu’il ne soit pas de la famille proche ou lointaine ou par alliance du président actuel Zine El Abidine Ben Ali.

C’est que j’ai revu mes ambitions à la baisse. A cette étape de l’histoire de nôtre jeune Tunisie, on devrait en être au pluralisme et à l’alternance à la présidence. Or nous avons pris du retard sur notre projet commun. En gérant des projets, j’ai appris que confronté à des objectifs aux risques (incertitude) élevés, il fallait choisir le plus essentiel et ce concentrer dessus. Il vaut mieux atteindre un seul objectif que d’essayer d’atteindre plusieurs et n’en atteindre aucun. On peut toujours atteindre un seul objectif, si on le choisi bien. Notre objectif principal sous le mandat Ben Ali était le pluralisme l’alternance à la présidence. Or nous ne l’avons pas atteint. Nous avons pris du retard.

Quand on prend du retard, la situation change, et il faut revoir ses objectifs. C’est pour cela que mon objectif principal maintenant, c’est d’avoir un président méritant en 2024. Ensuite nous reprendrons les objectifs, et peut être que le pluralisme et l’alternance redeviendrons des objectifs principaux.

En quoi est ce que des parents de Ben Ali ne sont pas méritants?

Une petite discussion qui avait commencé sur la propriété intellectuelle avait fini sur les libertés individuelles et la philosophie de la loi. Une loi est toujours une atteinte à la liberté et donc une violence. Alors on ne restreint les libertés des gens qu’après s’être assuré de deux principes :

• La loi est essentielle (L’absence de la loi nuit à tout le monde)
• La loi pénalise le minimum de gens (On s’assure que les limites de la loi sont bien définies)

Un parent proche ou lointain ou par alliance d’un président n’est pas éligible à la présidence de la république. Voilà une loi. Ce n’est pas une question de mérite et d’individus. C’est une question de système. C’est une loi. Avec cette loi, le système marche mieux et son absence nuit à tout le monde. En démocratie, le pouvoir devrait être distribué au mérite : plus tu est intelligent et talentueux, plus tu a du pouvoir. Or le pouvoir s’agglutine, il génère le pouvoir, c’est le talent d’Achille de la démocratie. En l’absence de cette loi, on risque l’accumulation de pouvoir sur des critères autres que le mérite. On est même sûr, d’un point de vue historique que cela va arriver. Le dernier exemple de fiasco en date doit être celui de la famille Bush qui a laissé la démocratie la plus puissante du monde dans un état lamentable. On ne peut pas laisser l’avenir de notre pays au hasard des individualités, nous devons avoir une protection systémique contre ces dérives : une loi. Cette loi est essentielle. Et le nombre de gens qu’elle affecte est minimal.

Comment faire?

Il y a quelques temps j’ai regardé un reportage sur les bédouins du Sahara Marocain. Une petite tribu qui vit dans une oasis a une fascinante démocratie nominative pour élire le gestionnaire du puit. Pendant un quart d’heure le gestionnaire sortant était là à argumenter pourquoi il ne voulait pas être reconduit, mais il à été reconduit quand même. J’ai trouvé que c’était une bonne méthode pour résoudre la pénurie de candidats et l’absence d’information qui sont des problèmes majeurs dans la situation actuelle de la Tunisie. D’ailleurs c’est la méthode adoptée par le RCD pour élire Ben Ali candidat en 2009.

• Je m’engage à répertorier comme je peux, sur internet, les personnes aptes à devenir président de la république Tunisienne. Et je vous invite à m’aider.

Vous noterez que je n’ai pas exclu un membre du parti RCD du candidat X. C’est que je suis quelqu’un de raisonnable comme vous avez pu constater. Le RCD a été pendant longtemps le parti unique en Tunisie, il a 2 500 000 adhérents et probablement 99% des compétences et éxpériences politiques Tunisiennes. Nous avons 15ans d’ici l’échéance de 2024, il n’est pas déraisonnable d’espèrer qu’un technocrate apolitique fasse ses preuves et acquiert de l’éxpérience; mais quitte à assurer nos arrières, n’excluons pas les membres du parti RCD.

Cela dit, cette grosse oligarchie qu’est le RCD est la cause principale de l’échec de la pluralité pendant toutes ces années. Je les tiens pour responsables. Je pense que cette grosse structure à besoin de réformes plus encore que le pays. Et si vous voulez le fond de ma pensée, cette structure a besoin d’une scission. C’est une solution qui a été éprouvée en économie, et il y a une loi pour ça : ça s’appelle la Loi Anti Trust.

Mais on n’a pas besoin d’en demander tant au RCD. Au jour d’aujourd’hui, il n’y a pas plus apte que le RCD à livrer un excellent X aux éléctions de 2024. Et c’est tout ce qu’on demande. Un candidat dont la victoire est tellement assurée, qu’il peuvent se permettre de laisser les concurrents s’activer sur le terrain et les médias. Un candidat qui affronte les autres candidats dans des débats et gagne. Et ils peuvent le faire, mais pour cela il leurs faudra réformer leurs bases (الشعب و لجان التنسيق)  pour qu’ils ne faussent pas les éléctions par simple habitude et leurs sommets pour qui’ils dégagent X.

• Je m’engage à me rendre disponible autant que je peux pour discuter de ces idées au prés des membres sérieux du RCD. Et je vous invite à faire de même.

Pourquoi la situation est grave pour la Tunisie?

Le problème majeur en réalité, n’est pas celui des éléctions, ni de la pluralité ni même de la démocratie. C’est encore plus grave que cela. C’est un problème sociétal : un problème de confiance. Faut il rappeler que sans confiance, il n’y a pas de société. Tout marche à la confiance : le transport, les banques, le commerce,… tout. Et on ne construit pas la confiance en quelques années. C’est pour cela que c’est grave. Nous avons pris du retard. Pire encore on peut perdre la confiance, en une fraction de seconde. Cette bète est très difficile à manier. En réalité il n’y a que deux manières de construire la confiance :

• La délégation d’autorité (Je vous fait confiance, donc je fait confiance à ceux à qui vous faites confiance)
• L’historique (Je connais votre historique)

Ce qui est problématique c’est que nous en sommes à un point ou la délégation d’autorité n’est plus applicable : il n’y a plus d’autorité. Et je ne parle même pas de politique. Le système médiatique est tellement pourri, que s’il y a des autorités (intellectuelles par exemple) il est impossible qu’on les connaisse, ou si on les connais elles ne peuvent pas s’exprimer librement, donc on les prend pour des cons. Au début de la république, Bourguiba à bénéficié d’un bonus d’autorité que nous n’avons pas sû faire fructifier, et je fais porter encore une fois la responsabilité au RCD. Mais nous n’en sommes plus là. C’est pour cela que je me propose de répertorier les autorités Tunisiennes sur internet.

Les problèmes de confiance affectent notre vie de tous les jours. Pendant le mois de ramadan, quand on dit au tunisien qu’il n’y aura pas peinurie d’oeufs, il sacce quand même les supermarchés et en conséquence il y a peinurie. Les taxis n’ont pas confiance, les policiers n’ont pas confiance, les juges n’ont pas confiance, les journalistes n’ont pas confiance,les hommes d’affaire n’ont pas confiance , lles hommes politiques n’ont pas confiance. Chacun pour soi. Pas de société. Le seul moyen qui reste de bâtir la confiance c’est l’historique, et ça, ça va prendre du temps. Le plus tôt on commencera, le mieux ce pays se portera.

La plus ancienne base de données du monde : un cimetière

La conversation a commencé juste après le barcamp . Nous sommes allés prendre un petit café, Jazem, Houeida, Hatem, Kais et moi; et la conversation avait tourné autour des bases de données. Plus tard la conversation à continué entre Kais et moi par messagerie instantanée. Et encore plus tard avec Pr. Hatem Ben Sta au Caire. Ce que j’essayais d’expliquer, en mode non structuré mais caractéristique des conversations en direct, c’est pourquoi je me méfie des ORM, pourquoi nous n’utilisons pas de framework à ALIXSYS et comment on fait.

Quand vous écrivez une application qui, d’un côté est basée sur un modèle objet, et d’un autre côté fait appel à une base de donnée relationnelle pour stocker les données, vous avez  la désagréable impression de vous répéter et que toutes ces lignes de codes ordonnant a vos objets de s’enregistrer sont de trop. C’est normal. C’est que, comme l’expliquait Dan Ingals (à moins que ça ne soit Alan Kay, citation approximative de toutes façons) : « Dans la vraie vie, quand on rempli un Verre d’eau, on ne lui demande pas de se « mémoriser » juste après. ça n’a pas de sens. » Un système basé sur un modèle objet devrait gèrer le stockage des données de manière transparente, sans intervention du programmeur.

Mais alors pourquoi les programmeurs persistent à utiliser des SGBDR ? Principalement par habitude, mais quelques fois aussi par souci d’intégration. En environnement d’entreprise, vous avez souvent ces conditions :

• Un ou plusieurs SGBDR sont déjà déployés et en production
• Les développeurs ont l’habitude de développer des applications basées sur SGBDR
• Des applications décisionnelles (reporting, BI, etc…) sont déployées sur les SGBDR et le personnel est formé à leurs utilisation

En résumé SQL est un standard. Les gens ont tendance à l’oublier, mais SQL est probablement le standard le plus puissant du monde informatique. Le nombre de programmeurs qui parlent SQL doit être plus grand que ceux qui parlent HTML. SQL est plus puissant que HTML.

Écrire du code c’est écrire. En soi, ce n’est pas très différent d’écrire un poème, une facture ou sur un mur. Le but principal, au delà du langage, c’est de se faire comprendre; si possible par le plus grand nombre. Un standard est précisément fait dans ce but : pour que tout le monde parle la même langue. Et ça, ça n’a pas de prix.

Cette situation pose un dilemme : Objets ou SQL ? Et les réponses proposées sont :

1. On abandonne la POO
2. On abandonne SQL et on adopte smalltalk
3. On abandonne SQL et  on adopte un système de stockage non relationnel
4. On adopte un ORM
5. La réponse 5

Je vous déconseille de prendre le 50/50, je vous le donne en mille : ce sont toutes des mauvaises réponses. Mais ce sont là toutes les réponses envisageables à l’heure actuelle. Même si adopter smalltalk est tentant, vivre en autarcie n’est pas une option pour tous les projets. CouchDB, TokyoTyrant, BigTable et autres systèmes de stockage non relationnels ont le vent en poupe en ce moment, mais ils ne résolvent pas nôtre problème (Le stockage automatique et transparent des objets; juste pour rappeler). Il reste l’ORM. Qui résous bien partiellement le problème mais qui a l’énorme inconvénient de cacher SQL de la vue du programmeur. Ce qui est bien du point de vue des concepteurs d’ORM mais mal de mon point de vue.

Les standards aussi sont une écriture. Et à ce titre, je considère que leurs finalité c’est d’être lus, compris et appliqués par des hommes et non pas des machines. C’est ce qui fait la différence entre un bon standard et un mauvais comme SOAP et ses dérivés. On n’écrit plus du code comme en 1980, c’est devenu un travail collaboratif. En 1980 écrire du code ressemblait à une conversation privée entre vous et la machine. En 2009 écrire du code ressemble à un talk show : vous avez bien un animateur-ordinateur en face de vous, mais la conversation est devenue publique. Le code est devenu public. Libre. Formellement, vous vous adressez à l’ordinateur, mais pratiquement, vous vous adressez à d’autres programmeurs. Et tous ces programmeurs parlent SQL, ça serait dommage de ne pas en profiter.

Les « leaky abstractions » à la rescousse

Un Objet est une abstraction de très haut niveau. Elle permet de représenter toutes les choses de l’univers. Elle permet aussi de représenter plein d’abstractions de niveau plus bas. Avec un Objet, on peut tout faire. Notamment créer un Objet/Abstraction nommé Base de données.

Mais construire des abstractions est un art. Une bonne abstraction doit cacher ses détails. En mathématique, si j’utilise « n » comme abstraction pour représenter un nombre entier, c’est bien pour m’éviter de raisonner sur les 1, 2, 3 et autres 4 et 5 de toute la suite individuellement. Ce qui me serait impossible de toutes façons. « n » est une bonne abstraction parce que, avec, je peux prouver que la somme de deux entiers est un entier par exemple . Maintenant, si j’utilise le symbole ☹ comme abstraction pour représenter « tous les nombres contenant le chiffre 7 ou multiples de 666″, outre le fait que c’est complètement débile comme vous pouvez le constater, je ne peux rien faire avec mon ☹ sans devoir me rappeler ce qu’il représente. La suite 7, 17,  27, 37, 47, 57, 67, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 87, 97, 107, 117,  127, 137, 147, 157, 167, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 187, 197, 207, 217,  227, 237, 247, 257, 267, 270, 271, 272, 273, 274, 275, 276, 277, 278, 279, 287, 297, 307, 317,  327, 337, 347, 357, 367, 370, 371, 372, 373, 374, 375, 376, 377, 378, 379, 387, 397, 407, 417,  427, 437, 447, 457, 467, 470, 471, 472, 473, 474, 475, 476, 477, 478, 479, 487, 497, 507, 517,  527, 537, 547, 557, 567, 570, 571, 572, 573, 574, 575, 576, 577, 578, 579, 587, 597, 607, 617,  627, 637, 647, 657, 666, 667, 670, 671, 672, 673, 674, 675, 676, 677, 678, 679, 687, 697, 707, 717, 7 27, 737, 747, 757, 767, 770, 771, 772, 773, 774, 775, 776, 777 est bien représentée par ☹ mais pour la créer j’ai du traiter séparément les 2 cas : 7 et 666. ☹ n’est pas une bonne abstraction.

Ce genre d’abstractions, Joel Spolsky les appelle « leaky abstractions« , littéralement « les abstractions qui fuient » comme un robinet,  parce qu’elles laissent transparaitre leurs charpente. Il va même plus loin, il théorise : « Toutes les abstractions non triviales fuient ». Si on examine les abstractions utilisées par Ruby on Rails pour son ORM, cela se confirme.

D’abord RoR fait une simplification : 1 classe = 1 table ce qui n’est pas toujours la solution optimale. Nous avons pu constater par exemple que avoir plusieurs classes utilisant la même table est une situation assez commune de par son optimalité. Par exemple, pour la plupart des systèmes vous avez plusieurs classes d’utilisateurs : Clients, Commerciaux, Administrateurs, etc… Nous avons trouvé que utiliser 1 seule table et plusieurs Classes pour les utilisateurs est une solution optimale.

Ensuite RoR utilise des abstractions du genre « has_many: », « has_one: » pour représenter les relations entre les objets. Or ces abstractions sont très peu expressives pour représenter les relations entre les objets. Les objets peuvent avoir toutes sortes de relations : une Souris:mange(Fromage) un Chat:chasse(Souris) . Ce qui est exprimé en réalité dans RoR ce sont les relations sous-jascentes dans la base de données. Vous voyez la fuite (leaky abstraction)? Cela ne m’étonnerait pas que les programmeurs RoR finissent par construire leurs modèle objet en pensant aux tables qui vont être créées dans la base.

Quitte à avoir un modèle conscient de sa condition d’objet informatique volatile, nous allons le faire parler carrément SQL avec la base de données. Observez ce petit bout de code PHP :

$senefer = Creature::select("where name like 'Sanfour %'");
$ghadhbaan = new Creature("Sanfour Ghadhbaan");
$ghadhbaan->insert();

J’en vois certains qui sont en train de s’arracher les cheveux. Mais vous avouerez que la clareté de ce code est incontestable. Ce modèle déroge aux règles les plus élémentaires de la conception : le code est strictement lié au modèle de la base. Si on change la base on doit changer le code. Mais les autres ORM y dérogent aussi. Et j’ai horreur de faire semblant. Je préfère faire avec. Et vous verrez dans un moment que ce n’est pas si grave que cela.

La méthode select() est statique et c’est une factory. Elle génère des objets de sa Classe.

$senefer[0] instanceof Creature; //retourne TRUE

Ce genre de méthode dans sa plus simple expression est très simple à écrire :

class Creature
{
  static function select($options = NULL)
  {
    $resultats = self::$db->query("select nom from creatures $options");
    foreach ($resultats as $ligne) {
      $creatures []= new Creature($ligne['nom']);
    }
    return $creatures;
  }
}

Ici on voit bien la liaison stricte entre le code et la base. Mais dans la pratique, il est de toutes façons impossible changer la base sans changer le code d’une manière ou d’une autre. Ce qu’on fait, généralement, c’est confiner le code qui peut changer de manière à ne pas avoir à le chercher. Et dans cette optique, je trouve que le code est assez bien confiné dans cette simple méthode select(). Si par exemple il nous vient à l’idée de changer le nom du champ « nom » en « nom_et_prenom » dans la table « creatures ». Nous aurions simplement à changer le code comme suit :

class Creature
{
  static function select($options = NULL)
  {
    $resultats = self::$db->query("select nom_et_prenom as nom from creatures $options");
    foreach ($resultats as $ligne) {
      $creatures []= new Creature($ligne['nom']);
    }
    return $creatures;
  }
}

PHP est une simple couche au dessus de la base de données, comme aiment à le dire ses détracteurs. On se propose de l’utiliser comme tel et d’en tirer parti. Je ne concevrais probablement pas mon modèle de la même manière si j’écrivais du code en Scheme.

La méthode insert() est dynamique. Dans sa plus simple expression l’implémentation ressemblerait à :

class Creature
{
  function insert()
  {
    $nom = $this->nom;
    self::$db->query("insert into creatures (nom) values('$nom');");
    return $this;
  }
}

Pour formaliser tout cela nous pourrions faire une petite interface :

interface presistance
{
  public static  function select($options = NULL);
  public function insert();
}

C’est tout ce dont on a besoin.

Ou sont passées update() et delete() ?

Nous avons pu constater, au bout de quelques années d’expérience quand même, que supprimer des données dans une base de données n’était pas du tout naturel. Le plus souvent les données sont plutôt marquées comme « supprimées » (ou annulé ou désactivé etc …). Dans les faits la requète « delete » est plutôt une requêtes de maintenance (optimiser la performance de la base) et de ce fait, dans la plupart des cas ne fait pas partie du système.

Nous avons pu constater aussi que les opérations de mise à jour des données « update » sont souvent complexes, impliquent plusieurs tables à la fois et quelques fois même transactionnelles. Une opération update() qui synchroniserait l’objet avec ses tables dans la base de données, dans la pratique, serait mieux implémentée conceptuellement comme une suppression (ou annulation ou désactivation etc…) suivie d’une nouvelle insertion. Par contre l’opération de suppression de l’objet utilisera forcément la requête  « update » formulée dans une méthode spécifique à l’opération :

class Creature
{
  function tuer()
  {
    $nom = $this->nom;
    self::$db->query("update creatures set supprime='oui' where nom='$nom'");
    return $this;
  }
}

Cette méthode est capable de tuer un sanfour. Ce qui est une prouesse : on n’a jamais vu un sanfour se faire tuer. Mais tuer() est la méthode appropriée pour supprimer un sanfour.

Cette conception a été utilisée sur plusieurs projets et si je vous en parle maintenant c’est que nous avons pu tester son efficacité et sa simplicité. Ce dernier point est très importants pour nous. Veuillez observer ce schema illustrant notre process :

Process ALIXSYS

Si j’ai mis « Former les développeurs » ostentatoirement au début du process, c’est pour insister sur la consommations de resources en amont et combien il est important d’optimiser cette activité. Vous me direz : mais vos développeurs sont déjà formés. Oui, mais on recrute.

Quand nous avons fait la refonte de notre progiciel de géstion intégrée ALIX, il y a quelques années quand nous étions un département R&D dans une autre société, l’objectif principal identifié était de simplifier son accés aux programmeurs novices. ALIX était un système assez complexe avec une base de code assez importante qui faisait que quand on écrit du code pour ALIX on a à peine l’impression d’écrire du code PHP ou HTML : tout était caché derrière les bibliothèques et l’architecture du système elle même compliquait les choses. Nous avons tout reconçu depuis le début pour que quelqu’un qui a des connaissances rudimentaires en PHP puisse s’y retrouver dans le code et se faire utile très rapidement. C’était un impératif pour nous car nous avions un turnover assez important et nous recrutions souvent des jeunes diplômés.

Aujourd’hui ce n’est plus un impératif, mais cette expérience m’a permis de me rendre compte que avoir un système simple avec une base de code accessible donne un avantage compétitif certain. Prendre un frais diplômé et le rendre opérationnel comme développeur sur le système en 3 mois est certainement le trait conceptuel le plus attrayant du système ALIX. Et j’en suis très fier.

Cependant je ne suis toujours pas tout à fait satisfait. On peut aller plus loin. Et pour la version 3 de ALIX, je compte le débarasser de tout son code. ALIX sera alors un pur processus. Le rève.

Yet Another Why Google Should Buy Twitter. Ces derniers temps la mode et aux articles expliquant pourquoi Google devrait racheter twitter. J’ai décidé d’ajouter ma petite pierre à l’édifice.

Si vous êtes un utilisateur de twitter, vous avez peut être eu l’occasion de ressentir un « twitter moment ». Un twitter moment, c’est quand vous réfléchissez à haute voix sur twitter et qu’une voix étrangère vient corroborer vôtre réflexion. C’est déroutant. Déroutant mais jouissif. Par exemple : Vous dites « J’attend le bus depuis 30min, je vais être en retard » et une voix étrangère @taxidriver vous répond immédiatement : « Je viens vous chercher? ». Vous ne connaissiez pas @taxidriver auparavant, mais il va vous rendre immédiatement service.

Il est important de souligner ici la différence dans l’expérience utilisateur entre Google et twitter. Dans Google il faut chercher une information, même formuler une recherche. Dans twitter il vous suffit de communiquer votre état pour que des options vous soient présentées. C’est comme si il suffisait d’y penser. En tout cas ce n’est pas très loin.

Cette faculté de télépathie c’est la force de twitter. Si on l’analyse, on trouve que cette force trouve ses racines dans la dissymétrie entrée/sortie dans les systèmes d’information. L’entrée d’information et la sortie (consultation) d’information ont des fonctions et des propriétés totalement différentes dans un même système; quelque soit le système. C’est ainsi que toute la valeur ajoutée fournie par le système se concentre dans la sortie d’information. Il n y a aucune valeur ajoutée dans l’entrée d’information. Absolument rien. Un système d’information doit tendre vers un système idéal qui ne demande aucune entrée. Un système qui devine vos pensées.

Cette dissymétrie a de profondes implications sur tout le système. Par exemple, dans la plupart des applications, l’entrée n’a pas le même niveau de sécurité que la sortie d’informations. Vu qu’il n y a aucune valeur ajoutée a l’entrée d’information dans un système précisément, le niveau de sécurité de l’entrée d’information pourrait être très bas si le contexte le permet. En d’autres termes si votre système opère dans un contexte ou personne ne va chercher a fausser sciemment vos données, vous pouvez carrément mettre le niveau de sécurité au plus bas. Vous pouvez ne pas demander d’authentification pour les interfaces de saisie.

Cela dit définir un niveau de sécurité pour une interface utilisateur n’est pas si simple, puisque dans son interaction avec le système, l’utilisateur a besoin de feedback et donc de sortie d’information. Les interface utilisateur sont donc composites. Mais ce n’est pas une obligation, c’est à vous de voir.

J’utilise buxfer pour gérer mes petites dépenses. La consommation d’essence de ma 4L, les factures, etc… Pour saisir mes dépenses depuis mon vieux Nokia 6610i j’envoyais un mms a une adresse secrète. Jusqu’au jour ou Tunisie Telecom désactive le mms to mail sans aucune raison ni notice et que je me trouve obligé d’utiliser l’interface web mobile du service. Après quelques mois d’utilisation, je peux dire que ce n’est pas une solution idéale pour mes besoins. Le système m’oblige à m’authentifier trop souvent et c’est très pénible avec mon clavier 12 touches.

Je me suis dit que mes besoins sont très simples, que je n’ai pas vraiment besoin de représenter mes dépenses sous forme de camembert 3D tous les jours, et que ça serait mieux si je me faisais mon petit service sur mesure.

Ce dont j’ai besoin :

• Sélectionner une catégorie de dépenses le plus rapidement possible, sinon ça m’emmerde et je le fais pas
• Saisir un prix et un libellé optionnel le plus rapidement possible, sinon ça m’emmerde et je le fais pas
• Une fois par siècle, je consulte un état structuré de mes dépenses si possible manipulable avec un tableur

L’idée c’est que je ne vais pas demander un mot de passe pour saisir les dépenses, je vais juste demander un email comme identifiant. Quand vous voulez un état vous n’avez qu’a indiquer un email et l’état est envoyé a l’email en question. Voila pour la sécurité. A vue de nez le niveau de sécurité est amplement suffisant pour ma petite application. On verra à l’itération suivante si je devrais combattre le spam.

Je me suis donc retroussé les manches et le résultat c’est FLOOS essayez la sur votre téléphone portable (ça marche aussi sur votre ordinateur, mais ça n’a pas beaucoup d’interet). Et pour vous prouver à quel point je fais confiance au niveau de sécurité que j’ai établi pour l’application voici le code source de FLOOS. Si vous trouvez des bugs, ne soyez pas avare, c’est par ici les bugs : bugs FLOOS.

Les systèmes automatiques sont faits pour effectuer des opérations complexes tout en cachant la complexité a l’utilisateur. Si on ne fait pas attention en les concevant, ils cachent aussi la responsabilité. Pour pallier a ce problème, souvent, on ajoute des fonctionnalités de traçabilité : historiques et autres artefacts. Alors qu’il serait beaucoup plus effectif de concevoir le système dés le départ de façon à garder la responsabilité proche de l’utilisateur.

La responsabilité à un cout. C’est une sorte de taxe qu’on paie sur tous les produits qu’on en soit conscient ou pas. Quand elle est inscrite sur la facture, la responsabilité porte souvent le libellé : « Frais de gestion » ou « Assurance qualité ». Mais souvent, elle est sous évaluée. Bien évaluée, la responsabilité représentera probablement plus que 30% de la facture. Prenons un pain par exemple : c’est de l’eau, de la farine et du travail du boulanger. Dans le prix du pain, il y a le cout de la responsabilité du boulanger qui doit s’assurer que le pain est commestible et qu’il est de bonne qualité. D’ailleurs c’est principalement pour cela que les boulangers ne se valent pas. Mais il y aussi le cout de la responsabilité des services d’hygiène nationaux qui vérifient que les normes sanitaires sont respectées. Il y a le cout de la responsabilté de celui qui a vendu la farine et de celui qui a vendu l’eau et celui qui a loué le local. Chaque fois qu’il y a travail, il y a responsabilité et il y a un cout.

Maintenant, la responsabilité liée à un produit est fixe, elle ne peux pas être diminuée. Et la responsabilité ne se donne pas, elle se prend. Chacun est libre de prendre autant de responsabilité qu’il le désire. Mais pour l’acheteur, plus le vendeur prend de responsabilité moins il doit en prendre lui même. Parce qu’il faut bien que quelqu’un la prenne. Aussi plus de responsabilité engagée dans un produit est le seul argument de vente valable pour justifier d’un prix relativement élevé. Cet argument est souvent abusivement formulé : « meilleure qualité ». La qualité d’un produit c’est palpable, ce n’est pas un argument de vente. Et si le produit n’existe pas encore – le cas d’un logiciel ou d’une architecture – c’est qu’on parle d’assurance qualité et non pas de qualité. Et l’assurance c’est précisément le produit de la responsabilité. Il y a des vendeurs de responsabilité pure. Ça s’appelle les sociétés d’assurance.

A l’inverse, l’acheteur peut avoir une idée de la quantité maximale de responsabilité engagée dans un produit avec un calcul aussi simple que « 30% de la facture » à titre d’exemple. Si vous achetez un jouet a 5 dinars, la responsabilité maximale engagée dedans est de 1.500 dinars. Le reste c’est vous qui l’assumez, alors ne le donnez pas a un enfant.

L’autre jour, je me suis arrêté a un passage à niveau et j’ai attendu. J’ai attendu jusqu’à me rendre compte que le passage à niveau était probablement cassé : c’était une fausse alerte, « False Positive » en anglais, il n’y avait pas de train. A ce moment là je me suis demandé si le passage à niveau ne demandait pas une intervention humaine pour fonctionner. Le chauffeur aurait il oublié d’appuyer sur le bouton pour lever la barrière? Et c’est très dangereux. Tous les experts en sécurité vous le diront : une fausse alerte est presque aussi dangereuse qu’une vraie alerte. La preuve, j’ai contourné la barrière pour traverser. Si le même problème s’était reproduit encore une ou deux fois, j’aurais probablement pris l’habitude de contourner la barrière et je me serais probablement fait écraser un jour ou l’autre. Ne vaudrait il pas mieux avoir des systèmes automatisés pour ce genre de chose? Un capteur sur les rails et un déclenchement automatique et on n’en parle plus.

Non. C’est une question de responsabilité. Je ne m’y connais pas en passages à niveau, et après une petite recherche sur internet à ce sujet, je ne suis toujours pas en mesure de vous dire si c’est automatique ou manuel. Mais il serait probablement plus judicieux qu’ils soient manuels et assistés. Les systèmes automatiques, y compris les systèmes informatiques, ont une fâcheuse tendance à éloigner la responsabilité de l’utilisateur. Les systèmes automatiques sont faits pour effectuer des opérations complexes tout en cachant la complexité a l’utilisateur. Si on ne fait pas attention en les concevant, ils cachent aussi la responsabilité. Pour pallier a ce problème, souvent, on ajoute des fonctionnalités de traçabilité : historiques et autres artefacts. Alors qu’il serait beaucoup plus effectif de concevoir le système des le départ de façon à garder la responsabilité proche de l’utilisateur.

A ALIXSYS nous construisons des progiciels de gestion. Ce sont des applications critiques et nos clients nous demandent souvent de :

• « verrouiller »
• ajouter des contrôles
• diminuer des droits d’accès
• demander des confirmations à l’utilisateur
• etc…

Tout se passe comme si nos clients faisaient plus confiance au logiciel qu’aux utilisateurs, y compris eux mêmes. C’est que les erreurs humaines ont souvent des conséquences graves et il est tellement facile de faire en sorte que le logiciel les empêche… à première vue. Vue de notre bout de la lorgnette, la situation est différente :

1. Le système ne peux en aucun cas empêcher l’erreur humaine.
2. Le système est là pour donner du pouvoir aux hommes, pas pour les brider. Du pouvoir de faire des choses qu’ils ne pouvaient pas faire sans.
3. On préfère que les hommes se trompent plutôt que le système.

Oui. On préfère que les hommes se trompent plutôt que le système. C’est une question de responsabilité. Quand un utilisateur se trompe, on ne l’en empêche pas, on essaye de savoir pourquoi il s’est trompé. Dans 50% des cas c’est notre logiciel qui est en cause; mais dans 50% des cas c’est la procédure qui est en cause. C’est aussi notre métier de savoir quand un problème n’est pas de notre compétence et d’en informer le client. C’est le conseil. Quand c’est notre logiciel qui est en cause, dans presque tous les cas, le problème est dans l’interface utilisateur et il y a une meilleur solution que de limiter la liberté de l’utilisateur. Il suffit de changer la position d’un bouton, pour que plus personne ne clique dessus par erreur. Il suffit de changer le libellé d’un champ de saisie de chiffre, pour que plus personne ne tape des lettres dedans.

Quand le système se trompe, qui porte la responsabilité à votre avis? Oui, c’est nous. Et qui paie? Oui, le client. La responsabilité liée à un produit est fixe, on a dit. Alors à ALIXSYS, nous préférons que ça soit le client qui la porte quand c’est possible. Après tout, en déléguant la responsabilité, il ne délègue pas le risque (l’histoire de la responsabilité et du risque, je vous la raconterais peut être une prochaine fois). Alors c’est tout benef pour lui aussi. Avouez que c’est cocasse comme manière d’être compétitifs sur nos prix. D’aucuns tapent dans l’assurance qualité pour diminuer leurs part de responsabilité, nous ce qu’on fait c’est concevoir des systèmes où la responsabilité est d’emblée déléguée à l’utilisateur.

Voilà. Vous connaissez notre secret. Bossez maintenant.

La désynchronisation des activités est l’essence même de Ajax, c’est le « A » dans « Ajax ». Ces derniers temps, on commence a utiliser le terme « Ajax » pour dire « XMLHttpRequest » ce qui était prévisible : personne ne peux dire « XMLHttpRequest » sans attraper le hoquet.

Comme vous le savez déjà nous sommes en train de développer un Progiciel de Gestion Intégré (PGI) pour un grossiste en pharmaceutiques en Tunisie. L’activité de grossiste pharmaceutique est très particulière pour deux raisons :

1. le secteur pharmaceutique est relativement ancien et bien développé ce qui fait qu’il y a des « traditions »
2. le secteur pharmaceutique est très régulé pour des raisons de santé publique évidents

L’une des particularités du secteur c’est le traitement d’un nombre de commandes élevé dans une plage horaire très restreinte. Pour vous donner un ordre d’idée, ici, on traite à peu prés 900 commandes par jour dont 400 entre 11h et 13h. Il faut donc une logistique adéquate.

L’une des difficultés évidentes que nous avons identifiée depuis le début de projet, c’est l’interface de prise de commande qui allait être utilisée par les commerciaux. Les commerciaux sont généralement très peu connaisseurs en informatique : ils sont là pour appeler les clients au téléphone et saisir leurs commande le plus rapidement possible, par conséquent le niveau d’instruction est secondaire. Cela dit, vu la nature de leurs activité, ils maîtrisent parfaitement le logiciel qu’ils utilisent maintenant. Ils ont même développé des réflexes et des automatismes liés aux touches de fonction.

Quand nous avons présenté l’interface de prise de commande la première fois, nos interlocuteurs avaient des doutes. Pourtant la nouvelle interface etait loin devant l’ancienne en terme de fonctionnalités et même en terme d’ergonomie. Nous avons donc corrigé quelques détails par-ci par-là et donné l’application aux utilisateurs finaux pour la tester.

Le verdict fut unanime : la recherche des articles est trop lente. Quand vous cherchez un article dans les 7991 références, notre système met 300ms à répondre. Ce qui était beaucoup trop. Après avoir observé pendant une heure le plus expérimenté des commerciaux travailler sur l’ancienne application, j’ai été convaincu.

Après avoir étudié le problème et essayé différentes solutions, il n’y avait rien à faire : toute l’interface était à refaire. La seule solution était de grignoter sur les 300ms et pour cela il fallait reconcevoir l’interface.

La saisie d’une ligne de commande se passe comme suit :

1. L’utilisateur saisi les premières lettres de l’article recherché
2. Le système lui présente une liste d’articles qui correspondent à sa recherche
3. Il sélectionne l’article qu’il veut
4. Il saisi la quantité commandée
5. Il recommence

Pour bien faire son boulot l’utilisateur a aussi besoin de feedback. Il a besoin de savoir quelle est la quantité disponible en stock et d’être notifié en cas d’erreur (article mal saisi, etc…). Dans le système tel qu’il était conçu, il y avait une seule requête, ce qui nous avait semblé être un bon choix quand on avait conçu l’interface. La logique étant que 1 seule requête (Ajax) prend toujours moins de temps que plusieurs. Mais à y regarder de plus prés, l’activité pour laquelle on conçoit l’interface a une particularité qu’on peut exploiter : quand l’utilisateur veut vraiment (vraiment!) aller rapidement, il ne regarde pas la quantité disponible, il n’a pas le temps.

Ce que nous avons fait c’est séparer la consultation de la disponibilté en stock de la recherche d’article. En fesant cela nous avons gagné du temps doublement :

• d’abord nous n’affichons la quantité disponible que pour l’article séléctionné et non plus pour tous les articles retournés par la recherche, ce qui décharge le serveur.
• ensuite nous avons désynchronisé cette activité (remarquez les barres de synchro dans le diagramme) ce qui fait qu’elle se fait maintenant en parallèle avec la saisie de la quantité et donc ne prends plus de temps.

Cette nouvelle conception nous a permis de faire tomber la réponse du système à 30ms, et de réduire la responsivité perçue par l’utilisateur par – a vue de nez – un facteur 100. Notez aussi que nous n’avons pas fait que désynchroniser la consultation de la disponibilité en stock, nous avons aussi désynchronisé tous les autres feedbacks du système y compris l’affichage de la ligne saisie elle même (remarquez les 3 points de fin d’activité).

La désynchronisation des activités est l’essence même de Ajax, c’est le « A » dans « Ajax ». Ces derniers temps, on commence a utiliser le terme « Ajax » pour dire « XMLHttpRequest » ce qui était prévisible : personne ne peux dire « XMLHttpRequest » sans attraper le hoquet. Certains disent même qu’on fait tout et n’importe quoi avec Ajax et en fait ils veulent dire qu’on fait tout et n’importe quoi avec « XMLHttpRequest ». Je ne le pense pas. Je pense que « XMLHttpRequest » ne peux pas faire de mal, même s’il est utilisé n’importe comment.

Nous sommes actuellement en train de tester la nouvelle interface avec les utilisateurs et vous savez quoi? Aucun feedback. Ils disent rien les utilisateurs. Ils utilisent l’application comme si tout allait de soi. Comme s’ils l’utilisaient depuis toujours. Et je me dis que faire des logiciels pour entreprise a cette différence par rapport à faire des applications grands public : l’efficacité prime sur l’effet. On n’est pas la pour faire du buzz, on ne veut impressionner personne. Et effectivement les utilisateurs ne sont pas impressionnés … mais ils ne se plaignent pas. Et c’est ça notre récompense.