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.

En réalité, ce qu’on perdait de vue c’est que cela serait vraiment pratique de pouvoir comparer les montant des factures à l’ancienne avec nos nouvelles factures avec un seul clic de souris. Si on avait ça, on le ferait tous les jours. C’est parce que, justement, examiner les listings était pénible qu’on le faisait pas tous les jours.

Je me plais à dire que, dans notre métier, la programmation en tant que telle n’est ni une étape du processus, ni une activité. Elle est là à toutes les étapes : préparation, conception, test, amélioration. Si on devait la définir par une abstraction dans le processus ça serait celle ci : “Contexte”. C’est une erreur conceptuelle très courante dans les processus préfabriqués que de considérer la programmation comme une étape.

Nous sommes actuellement en phase de test intensif avant déploiement. C’est une étape plus ou moins critique selon le projet, et pour ce projet-ci, elle est très critique. Nous sommes en train de migrer l’un des plus importants grossistes en pharmaceutiques vers un nouveau système d’information intégré.

La difficulté dans ce genre de projets est toujours la même et peut se résumer à cette phrase du client : “n’oubliez pas que <nom de l’ancienne application> marche très bien depuis <nombre d’années supérieur à 10>“. Quelle que soit la définition du client pour “marche très bien” et quelque soit sa perception de son bon fonctionnement, le contrat est là : il faut qu’on remplace une application qui marche par une application qui ne marche pas encore.

Concevoir des tests n’est pas toujours chose aisée : une fois qu’on sait ce qu’il faut tester et combien, le “comment?” demande souvent des masses de créativité ou de ressources. L’avantage d’avoir une ancienne application comme étalon, c’est que justement, toute une classe de tests devient évidente : beaucoup de fonctionnalités doivent fonctionner EXACTEMENT comme l’ancienne application.

Hassen était aux prises avec des listings contenant des centaines de factures issues de l’ancienne application. Le but était d’identifier les différences entre les nouvelles factures et les anciennes. et jusque là la seule manière de faire que nous avions trouvée c’est de comparer manuellement les montants (des centaines, je rappelle). J’ai regardé Hassen faire ça pendant quelques jours, puis j’ai eu l’inspiration. J’avais pas encore une idée, juste une piste : si ce vieux logiciel DOS pouvait imprimer sur une feuille, on pouvait le faire imprimer dans un fichier.

J’avais l’idée, mais je ne savais pas encore comment j’allais faire, ni combien de temps ça allait prendre et surtout je n’avais pas le temps. A ce moment là Bechir était venu à la rescousse de Hassen, ils faisaient ça en XP, alors je leurs ai proposé l’idée. Nous avons réévalué les taches de la semaine ensemble et avons estimé que cela ne valait pas la peine. Dans ces moments là, on a souvent la hantise du YAGNI : après tout, on ne va pas examiner les listings des factures tous les jours. Une fois que c’est fait, c’est terminé.

En réalité, ce qu’on perdait de vue c’est que cela serait vraiment pratique de pouvoir comparer les montant des factures à l’ancienne avec nos nouvelles factures avec un seul clic de souris. Si on avait ça, on le ferait tous les jours. C’est parce que, justement, examiner les listings était pénible qu’on le fait pas tous les jours.

J’avais laissé la porte ouverte, disant : “si vous sentez que ça va vous aider, je le fais”. Ils ont fini par me demander de le faire. ça m’a pris quelques jours pour essayer différentes solutions qui n’ont pas marché et pour trouver la solution qui marche : j’ai installé dosemu sur un vieux poste linux, je l’ai configuré pour envoyer tout ce qui était destiné à l’imprimante dans un fichier texte accessible sur le réseau et j’ai installé la vieille application dessus. J’ai même pris la peine d’écrire un peu de code pour transformer les listings malpropres en fichiers CSV parfaitement acceptables pour notre base de données.

Nous ne fûmes pas déçus. Avec le recul, maintenant on est sur qu’on y serait jamais arrivé sans avoir fait cela. La morale de cette histoire c’est : donnez du pouvoir à l’équipe, ce n’est jamais une perte de temps. Faites comme Abraham Lincoln , si vous avez 8 heures pour couper un arbre, passez 6 heures à aiguiser votre hache. ça vaut la peine.

je suis désormais patron d’entreprise. une très petite entreprise de 3 développeurs d’applications web que nous avons nommée ALIXSYS.

ALIXSYS est né de la scission de l’unité Recherche et Développement en Systèmes d’Information (RDSI) de AlphaStudios. En d’autres termes l’équipe ALIXSYS à toujours existé sous cette forme mais sous une autre appellation et sous une direction différente : j’étais le patron de l’équipe, mais j’avais moi même un patron.

A AlphaStudios j’étais “Directeur des Projets”, à l’époque j’avais estimé que le titre de “Directeur Technique” ne convenait pas parce que dans l’entreprise telle qu’elle était structurée tout était technique. Ce qui mettait sous ma responsabilité les deux unités constituant AlphaStudios : RDSI et Web et Multimédia (WM) . WM étant l’unité historique de AlphaStudios. AlphaStudios crée des sites web et des applications multimédia depuis 1997. Date à laquelle j’ai rejoins l’entreprise.

L’unité RDSI est née vers 2001 d’une constatation simple : nous avions des compétences trop importantes pour ce que demandais le marché des sites web et des (défunts) cdroms multimédia. Nous avons donc décidé d’investir le marché des applications pour entreprise et nous avons d’emblèe cru dans les applications web.

Notre idée première c’était de proposer une meilleure solution aux entreprises multi-sites qui jusque là travaillaient avec des applications client-serveur relativement couteuses à maintenir. Mais notre premier client aller nous orienter sur un autre marché auquel nous n’avions pas pensé : celui des sous traitants exportateurs.

Les sous-traitants ont typiquement un donneur d’ordre à l’étranger à l’égard de qui ils doivent montrer le plus de transparence possible. Nous avons donc développé pour cette société une solution simple qui permettait à son client de suivre la production sur internet. Mais les circonstances ne nous ont pas permis d’exploiter ce filon. Il n’en reste pas moins que je crois que nos solutions sont idéales pour les sous-traitants exportateurs et je compte engager ALIXSYS dans cette direction.

Vers 2003 nous sommes passés par un bref épisode de service web d’audience des médias. Malgré la brièveté (relative) et l’échec (certain) de ce projet, cela m’a néanmoins fait réaliser l’importance du SaaS comme modèle de vente de logiciel. à ALIXSYS nous développons, hébergeons et maintenons les applications de nos clients.

Au bout de quelques années de fonctionnement l’équipe à fini par développer un noyau d’application pour entreprise que nous avons appelé AliX. Plus tard l’unité RDSI sera rebaptisée AliX aussi. Ce noyau à servi par la suite de base à une série de Systèmes de Gestion Intégrés (ERP) que nous avons développés pour quelques entreprises tunisiennes. Cet expérience de l’entreprise Tunisienne fut capitale : un logiciel, au delà d’une certaine taille, n’est pas fait que de code; il est fait de négociations, de politique et de relations humaines complexes. je ne suis pas sûr que nous continuerons à faire des logiciels de cette taille là dans ALIXSYS.

Ces dernières années, j’ai fini par m’occuper exclusivement de l’unité AliX, devenue aujourd’hui ALIXSYS. Parce que Anis s’occupait très bien de l’unité WM et parce que cela me convenait parfaitement. Au début de cette année j’ai décidé que pour assouvir mes ambitions, et après 10 ans de travail, je devais fonder ma propre entreprise. J’en ai parlé à Zied, mon patron, et on s’est mis d’accord pour que j’attends encore 6 mois. Le problème étant que la survie de l’unité AliX était menacée sans moi. Mon idée à ce moment là c’était de faire la startup markkit. C’était risqué, mais j’étais volontaire.

Au cours d’une réunion un peu dure avec un client de AliX, le client décide d’arrêter son projet (ce sont des choses qui arrivent). L’étau se resserre sur l’unité AliX, mais je vois une opportunité. Je propose à Zied de séparer AliX de AlphaStudios et au client de travailler avec la nouvelle entreprise. Au bout de 4 mois de négociations ALIXSYS est né.

NOTICE IMPORTANTE : Après avoir lu cet article, ne m’envoyez pas d’email pour me demander pas de l’aide. Je ne fais pas de support. Débrouillez vous!

UPDATE : après avoir publié cet article la première fois, un site partenaire de payoneer a arrêté de fonctionner comme il faut. j’ai été obligé de changer l’article. Vous pouvez toujours voir la version originale de l’article ici. (un grand merci a Hatem Zidi pour avoir détecté le problème et m’avoir aidé à le résoudre)

Principe : nous allons utiliser 2 applications web.

• payoneer, est un fournisseur de services de payement électronique (comme paypal) qui à la particularité de fournir des cartes de crédit.
• odesk, un site de freelance en ligne

nous allons ouvrir un compte sur odesk, ensuite dans odesk nous allons choisir payoneer comme méthode de paiement et remplir un formulaire de demande de carte de crédit.

Comment faire?

1. allez a odesk.com et ouvrez un compte “Freelance provider”. renseignez toutes les informations qu’il faut, confirmez votre email et faites tout ce qu’ils vous disent.
2. cliquez sur “Billing & Payements”. ensuite choisissez la méthode de paiement “oDesk debit MasterCard”. (cliquez sur “Sign up now”)
3. vous allez être envoyé chez payoneer.
4. renseignez tous les champs dans le formulaire payoneer honnêtement. ils vont vérifier vos informations dans les bases de données de terroristes, personnes recherchées, et mauvais payeurs avant de vous donner leurs accord.
5. dans 48h vous allez recevoir une confirmation que votre carte vous a été envoyée. (ou pas!)
6. dans 1 mois vous allez recevoir votre carte par la poste.
7. votre carte sera bien évidemment vide quand elle arrivera (votre solde est à zéro). Vous devez demander à quelqu’un de vous la charger en utilisant le formulaire de recharge et votre email (c’est facile). Bien sur les frais sont relativement onéreux, mais avoir une carte de crédit internationale n’a pas de prix dans certaines situations.

Voilà pour ceux qui sont pressés. Pour les autres, vous pouvez lire mes aventures avec le système bancaire tunisien.

Comment est ce que j’en suis arrivé là?

Il y a quelque temps, je commençais à réfléchir à fonder ma startup. Je savais déjà qu’il y avait un problème qu’il fallait que je résolve rapidement : l’hébergement. Je savais, pour les avoir côtoyés, que je ne pouvais pas compter sur les hébergeurs tunisiens. Parce que d’abord ils sont tous dépendants de Tunisie Telecom et tout le monde sait le niveau d’incompétence de Tunisie Telecom, ensuite le niveau de compétence des hébergeurs est lui même à peine suffisant pour héberger des sites web d’entreprises. On ne peut décemment pas fonder une startup dessus.

Il fallait donc que j’héberge chez un hébergeur sur lequel je pouvais compter et pour cela il me fallait pouvoir payer en ligne. Donc il me fallait une carte de crédit internationale : c’est la méthode de paiement préférée des hébergeurs.

A l’époque Amen Bank faisait la promotion de la carte de crédit tayara, c’était une nouveauté : une carte rechargeable sur laquelle on met son allocation touristique avant de partir en voyage, pour ensuite l’utiliser à l’étranger. Je me suis donc rendu à la première Amen Bank que j’ai vue. C’est à dire en bas de chez moi. J’ai demandé d’ouvrir un compte, et… il n’y a pas de et. Ils ont commencé à me poser des questions sur où je travaille, où j’habite, combien était mon salaire et m’ont demandé une tonne de paperasse; comme si j’allais me qualifier pour quelque chose. Questions auxquelles j’ai refusé de répondre et je les ai envoyés se faire foutre dans un langage qu’ils comprenaient bien, le langage administratif : j’ai dit que j’allais “revenir demain” (نرجع غدوا).

Mais je n’étais pas découragé pour autant. Je savais que, si elle avait été compétente, la grosse dame, elle n’aurait pas atterri dans une agence pourrie de cité El khadhra. J’avais donc bon espoir. Je me suis rendu à la nouvelle agence Amen bank sur l’avenue (ou presque). Et effectivement j’ai été bien accueilli par un chef d’agence déjà visiblement compétent, il m’a tendu d’emblée les formulaires pour ouvrir un compte dés que je l’ai demandé. Ensuite nous avons commencé à discuter et j’ai commencé à expliquer ce que je voulais en faire de ce compte et de la carte en particulier. Et la j’ai senti un vent de méfiance. Il à commencé à me dire que je n’avais pas le droit de payer avec la carte sur internet. Ce qui était était complètement idiot car leurs publicité disait “réservez votre hôtel et achetez votre billet en ligne”. D’ailleurs le bonhomme, regrettant de s’être engagé aussi loin avec moi, à poussé l’idiotie à ses limites en me disant qu’il fallait que j’apporte mon billet d’avion (entre autres paperasses) pour obtenir ma carte. J’ai pris les papiers. Et j’ai dit que j’allais revenir demain.

Maintenant, il y a un truc que je ne gobe pas dans le secteur bancaire. Les intérêts de qui est ce qu’ils défendent? (معانا ولا معاهم) Ce n’est évidemment pas leurs intérêts puisqu’ils refusent des clients. Mais c’est pareil pour les assurances et toutes les reliques d’un système économique renfermé et basé sur les monopoles et le contrôle de l’état. Tout ça c’est de la faute de Ben Salah , que dieu protège son âme (et ça sera bien fait pour sa gueule, ce coco de mécréant) (update: Ben Salah n’est pas décédé, mais que dieu protège son âme quand même ce coco de mécréant. je dois faire gaffe, parce que vu mon patronyme, je risque d’être présent à son enterrement et je ne veux pas qu’on me regarde de travers) Cette attitude de méfiance est typique. Ces gens te mettent des bâtons dans les roues sans que personne ne leurs demande. Ils sont dans un système, où ils sont motivés par la peur de la faute au lieu d’être motivés par l’envie de faire mieux que leurs voisin. Tout ça c’est de la faute de Ben Salah.

Le dernier épisode se passe dans mon agence il y a quelques mois. Après mure réflexion, j’ai commencé à comprendre le système de cartel dans lequel évoluent les banques et les entreprises strictement controllées en général (assurance, etc.). Je me suis dit que ma banque offrait forcément le même service. Alors je me suis adressé à mon chargé de clientèle du jour (ils changent tous les six moi dans cette grosse agence, ce qui fait que toutes ces conneries de relation privilégiée, d’écoute, de suivi ne marchent pas. tant mieux. je sais à quoi m’attendre.). Effectivement, ils offraient ce service mais ne communiquaient pas dessus. J’ai demandé à faire la carte et cette fois je suis resté évasif sur ce que j’allais en faire. Après tout ça ne les regarde pas. Ils ont le droit de me donner la carte, qu’ils me la donnent. Si c’est interdit c’est moi qui encours les peines, non?

Hier j’ai reçu ma carte, d’où cet article.

Entre temps il à fallu que je me débrouille pour héberger markkit et pour avoir mon indépendance financière. C’est là qu’au détour d’un article de TechCrunch, je découvre payoneer. Je commente le fait que payoneer n’est disponible que pour les américains et que ça ne sert à rien puisque ce n’est vraiment utile qu’au tiers monde et Yuval Tal (directeur technique de payoneer) me reprends en me disant qu’il est possible pour tout le monde d’avoir une carte à travers leurs “revendeurs”. Ce faisant il m’indique là ou il faut regarder. Je remercie aussi un certain Bryn qui à été plus explicite. Achetez des CD chez lui pour tester votre carte

Le service de payoneer est particulièrement brillant parce qu’il réutilise de l’infrastructure existante largement déployée. Ceci est la caractéristique des bons business models : ils s’appuient sur les autres acteurs économiques et ne réinventent pas la roue. C’est pour cela que, par exemple, l’hydrogène comme carburant ne réussira jamais. Le BioCarburant qui va réussir, c’est celui que je pourrais mettre dans mon réservoir sans changer ma voiture. Mais c’est une autre histoire.

P.S. ce texte est une fiction. toute ressemblance avec des fait réels n’est que pur hasard. notamment la grosse dame de l’amen bank.

L’historique commencerait à la date ou on a commencé à s’intéresser à lui et finirait quand on ne s’y intéresse plus. Ce serait une sorte de prothèse mémorielle gérée qui garderait une trace de tout ce qu’une personne à vécu dans sa vie. incidemment.

Cette année, parait-il, la tendance est aux “life streams”. en français “historique public”. FriendFeed a fait fureur au SXSW, mais je trouve personnellement que soup.io est nettement supérieur. d’ailleurs voici mon historique public.

Tout a commencé avec les blogs. Ce fut la première forme d’historique public. L’idée première était le “journal”, plus ou moins intime, en ligne. Je me souviens que moi même à l’époque je n’en voyais pas l’intérêt. Ou plutôt je voyais l’intérêt pour celui qui lit mais pas pour celui qui écrit. Je me disais donc, comme beaucoup, que ce mouvement allait être éphémère.

Mon raisonnement pouvait se formuler de la façon suivante :

1. la société moderne à délibérément cassé le lien social pour éviter le tribalisme.
2. l’individu a perdu l’échange d’expérience dans l’équation. ce qui s’est soldé de conséquences très graves sur la société entière : les individus sont devenus de grands enfants qui ne savent de la vie que ce qu’ils ont vécu eux mêmes.
3. l’individu est en manque d’expériences. résultat deux directions : les expériences individuelles extrêmes (sports, modifications corporelles, etc…) et le “voyeurisme” (reality shows, blogs, etc…). Je met des guillemets a “voyeurisme” pour atténuer l’aspect péjoratif.
4. l’explosion des blogs. les gens veulent savoir comment les autres gens se comportent dans la même situation qu’eux. rien de plus naturel. c’est même la base de la réussite de notre espèce. maintenant on appelle cela “voyeurisme”, mais il n’y a pas si longtemps que cela, quand les villages étaient plus petits, on appelait cela “potins”. comme s’il ne suffisait pas de rendre le mot “potins” péjoratif, il fallait inventer un autre mot plus effrayant.

Pendant un certain temps, la société a fait des villages de plus en plus grands alors que les moyens de communication sont restés les mêmes. Les gens ont préféré le confort et l’anonymat dans les grandes villes à la vie rustre et socialement riche des petits villages. Cela se comprends. On ne pouvait pas avoir les deux. Maintenant on peux.

Maintenant l’intérêt de celui qui profite de l’expérience est clair (le lecteur de blog), mais quel est l’intérêt de celui qui donne l’expérience (l’écrivain de blog)? La réponse est évidente : l’autorité. C’est évident parce que c’était déjà la même chose dans le petit village. Les schémas sociaux n’ont pas changé. Ce sont les moyens de communication qui ont changé pour s’adapter aux villages modernes.

L’autorité c’est l’historique. dans certaines cultures, on dit “l’ancien” pour désigner la personne à la plus forte autorité. La problématique de l’autorité et de la confiance est d’actualité parce que fortement liée à la sécurité. Et la sécurité c’est la science de notre siècle. D’ailleurs si nous vivons un changement de paradigme, le nouveau, c’est bien celui de la sécurité. Et si c’est le cas, nous ne pouvons rien faire contre. Espérons seulement que cela fera avancer le savoir dans le domaine des sciences sociales.

Firefox 3 vient de sortir. Parmi toutes les innovation en termes de sécurité, il y en a une qui n’est pas classée par l’équipe firefox parmi les innovations en sécurité et qui me semble, moi, la plus importante : l’historique infini. Quand vous naviguez sur internet, désormais Firefox pourra garder la trace de tous les sites que vous visitez. En d’autres termes, quand vous visitez un site, le navigateur pourra vous informer que vous êtes en train de visiter le site pour la première fois. Cela permettra par exemple d’éviter le phishing. Plus généralement, puisque vous avez accès à votre historique de navigation complet, vous pourrez estimer le degré de confiance que vous donnez à un site. La confiance aussi c’est l’historique.

L’historique est important pour établir une relation. Quand vous allez recruter quelqu’un, vous cherchez son nom dans google. Pour savoir si vous pouvez lui faire confiance et si c’est une autorité dans son domaine. Souvent le résultat de la recherche est confus, se sont des “traces” plutôt qu’un historique structuré. Surtout que les informations sont fragmentées : les photos sur un site, les videos sur un autre, les écrits sont même fragmentés sur plusieurs sites selon leurs natures : twitter, articles (certains ont plusieurs blogs), commentaires sur d’autres blogs, etc…

Interviennent alors les nouveaux logiciels spécialisés que sont les “historiques publics”. Vous leurs dites ou sont les informations sur vous et ils les agrègent dans un seul flux. De cette manière quelqu’un qui s’intéresse à vous peut vous suivre. Et vous pouvez aussi mieux gérer votre historique : modifier, supprimer les informations qui vous semblent non avantageuses ou simplement inutiles. Là, nous commençons a entrevoir les limites de la confiance. Celui qui gère l’historique, à le pouvoir sur l’historique.

Ce qu’il faudrait, c’est pouvoir gérer son historique et celui des personnes qui nous intéressent. Chacun pourra garder une copie de l’historique de n’importe qui. L’historique commencerait à la date ou on a commencé à s’intéresser à lui et finirait quand on ne s’y intéresse plus. Ce serait une sorte de prothèse mémorielle gérée qui garderait une trace de tout ce qu’une personne à vécu dans sa vie. incidemment.

Je crois bien que soup.io est bien parti pour être ça. s’il survit à sa jeunesse. longue vie a soup.io.

Le premier jour la salle était pleine d’étudiants mais ils n’avaient pas l’air très au courant. Le deuxième jour il y avait moins d’étudiants mais ils avaient l’air plus au fait des discussions. Comme si ceux qui étaient venus le premier jour avaient passé le mot : ça parlait de izoque, ipévéssisse, idééenne, yeutééeffe et de nemo.

Le 21 et 22 février 2008 se sont déroulées les Journées Tunisiennes de l’Internet. Le programme était subdivisé en trois parties :

• le matin de la première journée on a discuté de ISOC et IETF
• l’après midi de la première journée on a discuté des IDN et IPv6
• le matin de la deuxième journée on a discuté de IPv6 et NEMO

Les JTI2008 sont le premier évènement organisé par le chapitre Tunisien de ISOC. Khaled Koubaa, le président du chapitre était au summum du stress que peut supporter un être humain le premier jour. Il n’avait pas dormi depuis trois jours. Le deuxième jour, on voyait très bien qu’il avait passé une bonne nuit de sommeil. Tout s’était bien passé le premier jour.

Lamia Sghaier, notre secrétaire d’état, a confirmé un nouvel opérateur telecom et a annoncé une mesure qui me tient particulièrement a cœur : à l’horizon de 2009 l’état va fournir des adresses mel a tous ses citoyens. ce que je trouve particulièrement intelligent.

Patrick Vande Walle, chef de projet en charge des nouvelles technologies de l’information à la commission européenne (aussi membre de ISOC) nous expliqué les interactions en jeu dans la gouvernance d’internet. Il nous à révélé entre autres que ces derniers temps, l’OMC commence a s’activer pour être une autorité.

Marc Blanchet, auteur de plusieurs RFC autour des IDN, a inventorié devant nous les activités en cours de IETF et nous a expliqué qu’il y a de moins en moins d’activité autour de IPv4 et de plus en plus autour de IPv6. en d’autres termes IPv4 n’est plus maintenu. ce qui se comprend quand on sait qu’en 2010 il n’y aura plus aucune adresse IPv4 disponible. Il nous a aussi expliqué le processus de soumission d’Internet Draft, où je me suis rendu compte que c’était une simple question d’upload de fichier avec un formulaire. D’ailleurs Marc encourage out le monde a soumettre des drafts, et je pense que je vais m’y mettre. Il y’a un petit souci avec les IDN BIDI que je vais prendre la peine de régler.

Atef Loukil, de ATI nous a expliqué pourquoi il faut des noms de domaines en langue arabe. Ce qui est une question qui ne me serait jamais venue a l’idée de me poser. En généralement j’apprécie beaucoup ce genre de questions et en plus il a donné de trés bonnes explications étayées de chiffres très intéressants. A la fin de la présentation nous aurons appris que 99% des internautes qui parlent arabe parlent en même temps une langue latine, mais malgré cela il faut que les noms de domaines soient en arabe, parce que ce qui compte ce ne sont pas les internautes qui sont déjà sur la toile, mais bien les internautes potentiels.

Thierry Ernst, chercheur a INRIA et adepte du vélo, nous à fait part de ces recherches sur l’internet mobile et des résultats qu’il a obtenu. Nous avons appris que le frein à l’adoption de IPv6 se résumait au fait que IPv6 est une factorisation de IPv4. IPv6 n’est pas une innovation en soi, IPv6 permet l’innovation. Pour cela il faudrait d’abord qu’il soit mis en place. C’est ce que les industriels ont du mal a comprendre.

Ce que j’ai appris aussi…

• l’adressage IP est topologique. c’est a dire qu’une adresse dépends de ses adresses voisines. on ne peux pas attribuer des adresses au hasard. c’est justement pour ça que le DNS existe (pour attribuer des noms comme on veut)
• IPv6, contrairement a IPv4, permet d’adopter plusieurs politiques d’adressage. il n’impose pas un ordre hiérarchique (même s’il est utilisé de cette façon là pour l’instant).
• Dans IPv6 il n’y a pas de “adresse IP fixe”. toutes les adresses ont une durée de validité limitées et renouvelables.
• le rôle de rfc editor est très important, des RFC peuvent êtres éditées sans passer par le IETF (théoriquement) et d’autres peuvent être bloquées pendant des années (pratiquement)
• Les adresses IP sont des ressources. elles sont limitées (je n’y avait jamais pensé).

Ceux qui me suivent sur twitter ont pu suivre mes commentaires en temps réel. J’ai utilisé le tag “jti2008″ ce qui fait que vous pouvez les consulter sur hashtags.

D’un coup je me suis rendu compte que la console SQL que j’utilisais n’était pas pratique. J’ai fait quelques recherches, Bechir en a fait aussi et Hassen aussi. Aucun de nous n’a trouvé de console valable. Alors j’ai décidé de relever le défi. J’ai dit a Hassen de me donner deux week-ends; il m’en a fallu trois mais je pense que j’ai remporté le défi. le résultat c’est Bazdig, une console SQL écrite en PHP. Ce qui suit c’est un guide de mes choix conceptuels d’utilisabilité de Bazdig.

coloration syntaxique. très utile quand elle est bien faite. ce qui est important dans une requête ce sont les noms des tables et des colonnes. j’ai essayé de les colorer et laisser tout le reste en neutre. ca ne marche pas. il y’en a beaucoup trop et donc ca ne sert plus a rien. ce qui marche mieux, c’est de colorer les reperes. c’est a dire : “select”, “from” etc… comme ca on sait tout de suite ou sont les noms de tables et de colonnes.

le gros bouton “OK”. au début je l’avais mis sur toute la longueur de la page, mais je me suis vite aperçu que la plupart des bases de données avaient plus que 10 tables : le “schema browser” dépassait. je l’ai donc remis a la taille du champs texte et c’est mieux comme ça : tu va en bas pour “OK” et a droite pour explorer la base. Le raccourci clavier pour ce bouton c’est “k”. d’ailleurs les 5 boutons ont des raccourcis, glissez la souris dessus et ils vous diront ce que c’est. j’ai utilise la propriété accesskey de HTML, donc ça dépend du Browser. dans Firefox 2 c’est “ALT-SHIFT-k”.

le “schema browser” est l’élément qui m’a donné le plus du fil a retordre et je n’en suis toujours pas satisfait. j’ai passé plus que 50% du projet sur ce truc. je ne voulais pas le faire au début : l’idéal aurait été un “autocompleter” qui vous termine les noms de tables pendant que vous les écrivez. mais des fois on ne connaît même pas la structure de la base. il fallait qu’il soit toujours disponible et il fallait que la consultation soit la plus rapide possible. j’ai donc choisi le menu accordéon : ça prends pas de place, donc on peut afficher directement les tables (toujours devant les yeux, il n’y a rien de plus rapide) et c’est rapide a naviguer.

le titre est ici. il n’y a pas de titre a l’intérieur de la page parce que d’après mon expérience, il est superflu dans les applications. il est sensé servir de repère, mais la même fonctionnalité est fournie par la barre de titre. pour la plupart des applications le gain d’espace est plus important.

quand vous saisissez une requête et que vous appuyez sur “ok” vous atterissez dans le tableau de résultat. ici j’ai exploité au maximum les fonctionnalités du navigateur et j’ai empoché la sauvegarde des rapports et des requêtes sans rien mettre de ma poche. remarquez comment j’ai utilisé la propriété target=”_new” pour faire ouvrir a Firefox un nouvel onglet : maintenant je peux revenir a ma console en tapant CTRL-TAB, en prime je retrouve ma requête comme je l’ai laissée. Cette page ne fait appel a aucun fichier externe, même pas de feuille de style : tout est dans la page. comme ça, quand je sauvegarde la page, j’ai un seul fichier sur mon bureau. Firefox utilise le titre de la page pour fabriquer le nom de fichier a enregistrer; alors j’ai mis comme titre les noms des colonnes séparées par des espaces. comme ça, on n’a pas a changer le nom de fichier quand on enregistre.

j’ai choisi d’envoyer la requête SQL avec le protocole HTTP GET ce qui a pour effet d’imbriquer la requête dans l’URL. s’il y a un rapport que je dois consulter tous les jours, je n’ai qu’a le sauvegarder sous forme de “bookmark” (CTRL-d) et a chaque fois que je veux le consulter je clique. Bechir m’a dit que l’URL ne serait jamais suffisant pour les grandes requêtes, après quelques tests je peux conclure que c’est suffisant : n’oublions pas que Bazdig est une console, pas un éditeur. c’est très différent. une console est destinée a exécuter une seule requête à la fois. Franchement si tu fais une requête qui dépasse 200 caractères tu as un problème de modèle de données.

l’historique infini. c’est cette fonctionnalité qui m’a décidé a prendre mon courage a deux mains et faire une console SQL. Quand on accède a l’historique, Bazdig présente les 10 dernières requête. Notez que si vous exécutez la même requête 10 fois, Bazdig ne la présentera qu’une seule fois dans la liste. La requête sous le pointeur de la souris est mise en valeur avec un fond jaune, c’est pratique pour savoir ou on en est, plus pratique que de séparer les requêtes par des lignes. Quand on clique sur une requête elle apparaît dans la console.

on peut bien sur chercher une requête dans l’historique. il n’y a que dix résultats qui apparaissent, ne cherchez pas un bouton “page suivante” en bas des résultats, il n’y en a pas. Je suis d’accord avec Jesper Rønn-Jensen, il n’y a pas besoin : si les résultats ne vous plaisent pas , affinez votre recherche.

Ce qu’il reste a faire

• le “schema browser” est rapide mais pas ergonomique pour un sou. c’est un bug connu des menus accordéon : quand tu met le pointeur de la souris sur un bouton et que tu l’active, celui ci change de position. c’est déroutant pour l’utilisateur. ce que je vais essayer c’est changer la position du pointeur (!!) et le remettre sur le bouton. c’est contre toute logique UX mais ça m’amuse de le faire.
• ajouter la coloration syntaxique au historique. il faut garder les mêmes repères entre les interfaces. par contre je vais mettre plus en valeur les commentaires dans l’historique. comme ça on peut mettre des titres dans les requêtes.
• il y a des clics inutiles par ci, par la, qu’il faut enlever. notamment : je ne suis pas arrivé a trouver le moyen de donner le focus a la zone d’édition quand on accède a la console.
• la console doit se rappeler de votre base de données, même si vous revenez après une semaine. j’ai essayé de le faire en mettant le timeout du cookie a 1semaine, mais ça n’a pas marché. je vais aussi garder l’historique de vos bases de données et permettre le changement de base avec un seul clic.

Mon idée c’est que a l’instar de notre surprise face a l’audience de Tunis 7 les décideurs du ministère de l’intérieur seraient surpris de l’impact réel des informations jugées offensives. Et dans tous les cas je serais plus rassuré s’ils basaient leurs décisions de censure sur des données solides.

Au début du troisième millénaire, je travaillais sur le projet MAP. MAP était un service web d’audience des médias. Nos clients se connectaient dessus et pouvaient (entre autres) suivre l’évolution de l’impact de leurs campagnes publicitaires sur plusieurs médias.

Pour ce projet, notre partenaire était Institut El Amouri, un bureau d’études aussi ancien que l’industrie Tunisienne. Ils fournissaient la logistique (le projet impliquait des équipes d’auditeurs sur le terrain dans 3 grandes villes de la Tunisie), l’expérience et l’expertise; et nous on fournissait la technologie. Le contact avec les experts de Institut El Amouri fut une expérience extraordinaire pour moi malgré l’arrêt du projet au bout de 3 ans de fonctionnement. Je reviendrais peut être une prochaine fois sur les raisons de cet échec.

L’une des plus grandes surprise le premier jour ou on a mis en marche le serveur MAP fut l’audience de Tunis 7 : 70% . Personne n’arrivait a le croire, même pas l’expert de Institut El Amouri. et pendant une semaine, nous avons tout vérifié, des enquêteurs sur le terrain jusqu’aux applications sur le serveur. rien a faire c’était bien 70%. Cet épisode m’a appris quelque chose d’essentiel : notre jugement est souvent biaisé par notre propre expérience des choses. Le fait est qu’aucune personne de l’équipe, ni de son entourage ne regardait Tunis 7 en dehors de ramadan et par réflexe on pensait que tout le monde était comme nous. Il ne nous serait jamais venu a l’idée que notre comportement était minoritaire et que 70% de la population tunisienne regardait la série mexicaine de l’époque et le (pseudo) journal télévisé.

Ayant promis d’aider la censure a mieux faire son travail, je me suis dit qu’avec une idée plus claire sur l’impact réel d’une information sur la population notre ministère de l’intérieur ferait mieux son travail. Ayant très peu d’informations, je vais créer un modèle de travail et espérer qu’il soit ressemblant. Mon modèle approximatif de ministère de l’intérieur est le suivant :

• c’est une administration comme les autres
• toutes les décisions de censure passent par leurs agents
• les employés ne sont pas très motivés
• étant donné l’importance stratégique du ministère, la sélection des cadres se fait plus sur des qualifications politiques que techniques. les cadres ne sont donc pas forcément des gestionnaires.
• ils n’ont pas de règles de gestion écrites autres que ce qui est publié dans le JORT
• le processus de censure n’est pas maîtrisé. personne ne sait qui prend la décision, sur quelle base et quelles sont les actions a entreprendre pour chaque type de média (je suppose néanmoins que pour certains médias comme la presse, le processus est bien rodé).
• la question de la censure est taboo
• la décision de censure est déclenchée par une information reçue par le même réseau d’information qui sert pour le contre-terrorisme ou la sécurité de l’état. c’est à dire principalement des informateurs sur le terrain.
• il y a de la bonne volonté : certains employés veulent bien faire leur travail

Selon mon modèle le processus de censure de youtube s’est passé comme suit :

l’agent : comment ils ont fait?

l’indic : je te dis que je l’ai vu de mes propres yeux il mettent le film dans l’internet!

l’agent : dans la télévision de l’ordinateur?

l’indic : oui. avec la souris.

l’agent écrit son rapport comme il peut et l’envoie a son patron. le patron lis la première page du rapport et voit qu’il s’agit d’internet, il l’envoie a l’agent en charge de l’internet. ce dernier scanne des yeux les dernières pages du rapport a la recherche d’adresses de site web. puis passe un coup de téléphone :

l’agent : tu connais youtoube? coupe le.

Ici le problème c’est que la question du contenu est secondaire, la question de l’audience est impensable, la question de la décision est occultée. qui a réellement pris la décision? à mon avis c’est l’indic. c’est lui qui a décidé que youtoube était dangereux.

Mon idée c’est que a l’instar de notre surprise face a l’audience de Tunis 7 les décideurs du ministère de l’intérieur seraient surpris de l’impact réel des informations jugées offensives. Et dans tous les cas je serais plus rassuré s’ils basaient leurs décisions de censure sur des données solides.
Parmi les choses que j’ai apprises au cours du projet MAP c’est que dans l’arsenal du marketteur tunisien il y a essentiellement deux indicateurs :

• le GRP : Gross Rating Point, indique l’impact global qu’a eu une campagne complète
• le DAR : Day After Recall, indique l’impact qu’a eu une seule annonce

Adaptés pour internet, ces indicateurs seraient à mon avis calculés de la manière suivante :

• GRP : nombre de visites de la page en question (il n’y a pas de campagne définie dans le temps sur internet)
• DAR : nombre de personnes se souvenant d’avoir visité la page en question

Par conséquent pour mesurer le GRP, il suffit de regarder la page en question, souvent l’information sur le nombre de visiteurs est directement visible sur la page (c’est le cas de youtube par exemple) sinon des outils comme alexa peuvent aider. pour le DAR c’est un peu plus compliqué. j’imagine mal mon ministère commander une étude internationale pour savoir le DAR de la grève de Tunisie Telecom. Pour simplifier, on va utiliser un trait caractéristique des internautes : ils n’ont pas de mémoire, ils notent tout. s’il trouvent une page intéressante, elle a de fortes chance de se retrouver sur son blog, del.icio.us, twitter ou autres. Dans tous les cas google trends sera la pour capturer l’information.

j’ai appris que nous avons un nouveau syndicat de journalistes et que le site de l’International Federation of Journalists est désormais accessible depuis la tunisie. pour moi ce sont des signes de bonne augure pour 2008.