• Master tables
• Table1
• Table2
• Table3
• Slave tables
• Table1
• Table2

This scenario works pretty well except in one case. When you run a query on the master using the data of the Table 3

INSERT INTO Table2 (SELECT * FROM Table3 WHERE a=X)

The query will be transferred and run on the slave. But as Table3 does not exist on the slave, this will generate an error and pause the replication.

To make it work back, you will need to « skip » the query, this is done by running these queries on the slave

stop slave;
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
start slave;

This will enable you slave back.
ATTENTION : Skipping the transaction will make the new lines inserted on the master not replicated, you will need to replicate these lines manually, ideally deleting the lines and re-inserting them in a way it is « replicable »

Here we are going to see how to put in place a shell script that will poll our server any minute and send an alert if the slave is not replicating anymore.

What can we use ?

• mySQL provides a command

  SHOW SLAVE STATUS

  that gives several informations about the status of a slave

• The most important are Slave_IO_Running and Slave_SQL_Running which basically tell us that everything is fine if they are both on « Yes » and something wrong is happening if one is on « No »
• If one is on « No », this is likelly because there were an error in replication which is shown under the name Last_error

We can use the script of Matthew Montgomery that you can find online here : Check Replication Slave Status (or download directly check_slave.zip from here).

The script is very simple to use, it verifies that mySQL is running, ask for Slave_IO_Running and Slave_SQL_Running, if one is on « No », asks for Last_error and render this to the standard output.

So we copy the content of the script in a file called check_slave.sh that we put somewhere under /home (I use /home/scripts for all these kind of shells).

/usr/bin/wget \
http://blog.grossiord.net/wp-content/uploads/2011/07/check_slave.zip \
 --output-document="/home/scripts/check_slave.zip"
/usr/bin/unzip /home/scripts/check_slave.zip
rm /home/scripts/check_slave.zip

We chmod +x the file to be able to execute it.

chmod +x /home/scripts/check_slave.sh

We try to run « mysql » command directly to ensure that we are able to silently login to mysql. If this is not the case, this means that we need to add or update the password on ~/.my.cnf file. Exit mysql.

Run check_slave.sh, it should return nothing if everythig is fine.

/home/scripts/check_slave.sh

Stop the slave :

mysql -e "stop slave;"

Run check_slave.sh,

/home/scripts/check_slave.sh

it should return lines like

SQL thread not running on server xxxx!
Last Error:

Restart the slave :

mysql -e "start slave;"

Run check_slave.sh,

/home/scripts/check_slave.sh

it should return lines like

Replication slave is running
Removed Alert Lock

Everything seems to be well configured so we can put this execution in the crontab. I make it run every minute.

echo "*/1 * * * * root /home/scripts/check_slave.sh" \
>> /etc/crontab

which means that the script will run every minute, under the login « root ». If the local email is correctly configured, you will receive an email each time the replication has issues or it come back online.

NB. The script includes a flag mechanism that avoid it to send you an email every minute to tell you that the slave is out. You can parameter the time of the flags in the script on the line

repeat_alert_interval=15 # minutes

And this is it !

Have fun

Les uns en charge de faire venir des prospects pour les transformer si possible en clients, traités alors par l’équipe fidélisation qui devaient s’occuper d’en maximiser la valeur.

… c’était simple et surtout simpliste du point de vue du client qui basculait irrémédiablement dès qu’il entrait un numéro de CB ou saisissait un email du monde d’avant au monde d’après, sans même s’en rendre compte…

… car c’est exactement de cela qu’il s’agit ! On met un internaute dans une case ou l’autre alors que lui-même n’a pas vu pourquoi il devrait être traité différemment, logique, on est sur internet !

Un peu de contexte

Juste quelques rappels plutôt :

• dans le monde « physique », 55% des personnes qui entrent dans un magasins achètent (http://www.fifty-five.com/fr/pulse/) au moins un produit, sur internet, c’est plutôt 1 à 2%.
• pour un nombre croissant d’achats, un internaute passe sur les comparateurs de prix, puis passe sur les sites de bon de réduction avant de saisir son numéro de CB… et il a beau vous connaitre, il fera exactement la même chose la prochaine fois !

Cela amène quelques questions : comment construire une relation avec un internaute qui a vu 2 pages sur mon site et dont je ne connais ni le nom, ni l’email ? Comment distinguer mon futur bon client de l’opportuniste ? Comment ajuster une offre produit en fonction de du profil d’un internaute ? Comment connaitre des éléments de profil d’un internaute sans savoir qui il est ?

La gestion d’audience

L’Audience Relationship Management est l’application à des populations d’internautes anonymes de règles comparables à celles que l’on pratique depuis des années en Customer Relationship Management. Il va donc s’agir de mettre en place une communication directe auprès d’internautes dont on aura détecté une valeur probable en phase avec les objectifs de coût de commercialisation.

Le concept, s’il est nouveau dans son expression, est déjà mis en œuvre en partie au travers du retargeting par exemple : ré-exposer un internaute aux offres pour lesquelles il a montré un intérêt est une mécanique très proche du marketing direct. A ceci près que dans la plupart des implémentations actuelles, une société externe (Criteo, Next Performance ou MyThings) s’occupe pour le e-marchand de déterminer la valeur d’un client et que donc cette valeur est probablement nettement plus dépendante de la probabilité que cet internaute clique sur la bannière à cet instant que la lifetime value du client.

Le principe de l’ARM (oh, un nouvel acronyme, je ne l’avais pas celui-là !) est donc de déterminer la valeur potentielle d’un prospect pour un marchand en fonction des interactions qu’il a déjà eu avec l’enseigne et éventuellement de données externes de qualification et de s’en servir pour déterminer la « next best action » à mener sur ce prospect.

Après la destruction, voici le temps de la reconstruction et je me propose de vous exposer ici la solution que j’ai mis en place (et bien sur, je suis preneur de vos feedbacks !).

Petit rappel sur mon cahier des charges :

1. Doit permettre de générer un fichier de sauvegarde en minimisant à tous prix l’impact sur les bases de données de production
2. Doit utiliser un format de stockage compact qui permet de maintenir la sécurité des données
3. Doit permettre une restauration rapide avec le minimum d’opérations

j’y ajoute que ce moteur de sauvegarde doit me permettre de traiter des tables InnoDB et myISAM puisque je n’arrive pas à choisir (non, quand on est expert, on dit qu’on prend le meilleur des deux en fonction des opérations prévue sur une table donnée ).

Copie de fichiers

La méthode de sauvegarde myIsam la meilleure est la copie simple de fichiers (!), et oui, ça surprend mais si vous voulez sauvegarder le plus rapidement possible votre base de données myIsam, effectuez les opération suivantes :

• rsync du répertoire data de mySQL (on copie le plus gros des données, cela peut être long mais aucun impact sur les perfs de la DB)
• FLUSH TABLES WITH READ LOCK (on place un lock n’autorisant que la lecture des données)
• rsync du même répertoire (on ne reprend que les différences depuis le rsync 3 lignes plus haut, cela ne devait pas être trop long)
• On enlève le lock

Je ne suis pas (du tout) un expert du rsync alors je ne vais pas vous mettre de ligne de commandes, d’autres le font très bien et GIYF…

Quelques problèmes avec cette méthode :

• Impose un lock en écriture pendant quelques ms, s, min…
• Ne fonctionne que sur myIsam, en effet, sur InnoDB, même des lectures peuvent engendrer l’écriture dans les fichiers data, cette méthode risque donc de corrompre la base de données cible. Si l’on veut appliquer ce principe sur InnoDB, il faut nécessaire arrêter complètement mySQL.

Snapshot au niveau disque

C’est probablement la solution la plus « industrielle ». Dans ce cas, on fait un snapshot de l’ensemble des disques du serveur, avec LVM par exemple, et on est en mesure de tout récupérer « en l’état » en redémarrant sur le snapshot. C’est une solution séduisante, surtout si on veut jouer avec une configuration compliquée.

Cependant, cette méthode me parait difficilement utilisable pour les bases de données « uniquement » : si on veut se servir d’un backup pour lancer un nouveau SLAVE ou pour migrer la version de mySQL…

XtraBackup

http://www.percona.com/software/percona-xtrabackup/

Je n’ai pas trouvé d’autre script (gratuit) permettant de faire la même chose : sauvegarder le répertoire data de mySQL InnoDB et myIsam. En gros, après l’avoir fait tourner, on récupère un répertoire qui est la copie exacte et consistante du répertoire data de mySQL. Le transfert de ce répertoire vers un autre serveur suffit à avoir tout sauvegardé.

• La sauvegarde se fait au niveau fichier, pas d’impact sur mySQL
• Le format de stockage est le format natif du moteur choisi
• La restauration se fait simplement en plaçant le contenu de la sauvegarde vers le répertoire data du nouveau serveur

Pour l’avoir expérimenté sur diverses configurations et mis en place en backup quotidien, je suis très heureux de ce script que pourtant j’avais eu un peu de mal à trouver…

A vos commentaires !

La sauvegarde utilisée par la plupart des administrateurs mySQL est un script SQL généré au travers de l’outil mysqldump. Une commande type de mysqldump est

mysqldump --opt database > backup-file.sql

Le premier avantage de ce mode de sauvegarde est qu’il est « humainement lisible », on peut donc en extraire les parties qui nous intéressent pour d’autres sujets. Ce script a également l’avantage d’être la plupart du temps utilisable sur d’autres SGBD et est peu dépendant de la version de mySQL utilisée.

Il a cependant de gros désavantages

Génération du fichier de sauvegarde

La génération du fichier est couteuse en terme de performances pour le serveur mySQL en particulier lorsque celle-ci est volumineuse. Corollaire du précédent, si la génération du fichier prend plusieurs minutes / heures, on arrive à un fichier non consistant, toutes les tables n’ayant pas été sauvegardées en même temps.

Comme mysqldump envoie la commande de désactiver les Foreign Keys pour un futur import, on se retrouve avec une base de données corrompue.

Stockage du ficher de sauvegarde

On parle rarement de ce sujet, et pourtant cela me parait être à elle-seule une raison suffisante d’oublier ce mode de sauvegarde : la sécurité du fichier.

Quelque soit la finesse des droits que vous avez placé dans votre application et sur la base de données mySQL, votre fichier SQL est en plain text, lisible par n’importe qui. Si il est envoyé en FTP non crypté, s’il est accessible en HTTP ou s’il est stocké sur un CD, vos données sont récupérables. Si le contenu de votre base est une suite d’articles postés sur internet, ce n’est pas un gros problème, mais si vous y avez stocké des informations client, ou bien pire, il est temps de se préoccuper de l’endroit où naviguent vos fichiers SQL…

Évidement, le fichier est du SQL et est non compressé, à minima, il faudra donc y ajouter un gzip pour ne pas consommer de l’espace inutilement (et puis c’est plus facile pour l’embarquer sur une clé USB – cf point précédent )..

Restauration

On touche ici le point le plus sensible de la sauvegarde : on ne peut pas parler de sauvegarde sans parler de restauration. On le sait tous, j’enfonce des portes ouvertes, et pourtant…

J’ai eu l’occasion il y a plusieurs mois, dans le cadre de la migration d’un serveur, de devoir restaurer la sauvegarde mySQL d’une base de 40 Go. Heureusement que ce n’était pas une récupération après un sinistre ! il a fallu plusieurs jours (oui, JOURS) pour récupérer la base. J’ai pris le fichier SQL, je l’ai saucissonné pour le rendre plus digeste, j’ai tenté les autocommit = false (sur innoDB), etc, etc…

J’ai donc dit et redit à qui voulais bien l’entendre et je profite de cette chronique pour le redire : une sauvegarde doit permettre une restauration dans le MINIMUM de temps. Idéalement, le fichier de sauvegarde doit être utilisable « en l’état » pour relancer une base de données.

Cahier des charges d’un outil de backup de base de données

Ma conclusion intérmédaire de la définition d’un outil de sauvegarde de base de données en quelques points :

1. Doit permettre de générer un fichier de sauvegarde en minimisant à tous prix l’impact sur les bases de données de production
2. Doit utiliser un format de stockage compact qui permet de maintenir la sécurité des données
3. Doit permettre une restauration rapide avec le minimum d’opérations

Force est de constater que mysqldump n’est pas un outil de backup puisqu’il ne satisfait aucune des conditions que j’estime « basiques ».

Heureusement, il y en a de vrais ! (suite bientôt)

Commençons par la définition de ce que j’appelle « gros volume » : une base de données dont la taille totale est supérieure à 10 Go ou une base de données comprenant des tables dont le nombre de lignes excède 1 million. Ces nombres sont arbitraires, peuvent paraitre élevés ou non, ce sont ceux à partir desquels, de mon expérience, le mode de gestion « classique » de mySQL devient insuffisant (et aussi la doc officielle !).

Qu’est ce que le mode de gestion classique (d’autres diront « basique ») ?

• comme mySQL fonctionne « out of the box » et est souvent pré-installé sur un serveur Linux, on ne se soucie par trop du my.conf et on se dit qu’on ira plus tard « fine-tuner »
• on utilise une commande mysqldump copiée d’un blog pour faire la sauvegarde quotidienne
• on n’a JAMAIS qu’on est capable de restaurer la base de données avec le script généré ci-dessus
• on n’a ENCORE MOINS mesuré le temps qu’il fallait pour redémarrer un serveur mySQL avec le script ci-dessus

Je me propose sur plusieurs articles de discuter de la problématique particulière des gros volumes dans ce contexte, je n’ai pas trouvé (encore) les réponses à tous mes problèmes et suis bien sur preneur de retours d’expérience !

Une liste des fonctionnalités (non exhaustive)

• Post par email
  Vous envoyez un email à une adresse qui vous est propre et le contenu de l’email est publié. Y compris si l’email contient une photo ou une video, etc.
• Applications iPhone, Blackberry et Android
• Support de tous les formats de posts (texte, photo, videos, liens, etc.)
• Mix entre blog « classique » et microblogging
• Posts sur Twitter, Facebook
• Récupération de flux d’autres blogs ou de Twitter
• Customization des thèmes à partir d’une bibliothèque de centaines de thème
• Customization avancée des thèmes pour les experts
• Pas de pub et une signature « tumblr » discrète qu’on peut même désactiver gratuitement

Et surtout, surtout une interface très bien travaillée.

Pour moi, il semble que ce soit le must des gratuits que je recommanderai chaudement aux personnes non expertes ! Last but not least, c’est complètement gratuit.

D’où ça vient ?

Le protocole http : il a été inventé à l’époque où l’objectif était simplement de télécharger des documents et de naviguer des uns aux autres. Il n’était pas question de transactions en ligne et le protocole inventé s’est voulu simple.

Décrivons rapidement l’échange

• On tape une URL dans le navigateur : http://www.unsite.com/document.htm
• « http:// » indique au navigateur d’utiliser le protocole http
• le navigateur fait un appel DNS pour avoir la traduction de www.unsite.com en adresse IP (disons 10.10.10.10)
• il se connecte à 10.10.10.10 sur le port 80 (le port du protocole http)
• envoi une commande « GET /document.htm »
• reçoit la réponse du serveur (le contenu du document)
• il ferme la connection
• il interprète le contenu du document html et va chercher les éléments connexes de la page (images, feuilles de style, etc.)
• pour chaque élément de la page, il effectue la même opération (ouverture de la connection, envoi de la commande GET, réception de la réponse, fermeture de la connexion)

Comme vous avez pu le voir, le protocole http considère que chaque demande est nouvelle, c’est un protocole « pauvre » qui ne maintient pas de session (même le protocole d’échange du minitel était plus riche ). Il est largement suffisant pour aller chercher une page html ou une image mais ce manque de session pose un problème lorsque l’on est dans une application, il ne permet même pas de maintenir la connexion d’un internaute ayant tapé un login / mot de passe.

Pour pallier ce manque du protocole http, des solutions ont été imaginées au travers des cookies. Un cookie est une chaîne de caractère envoyée par le serveur à la première connexion au navigateur. Elle est ensuite renvoyée par le navigateur avec chaque commande « GET » au serveur.

Utilisation « standard »

Une application typique génère un contexte à la première connexion d’un internaute associé à un identifiant. Il envoie l’identifiant du contexte au navigateur qui le lui renvoie à chaque requête. Ce système permet de gérer une session et de suivre les actions de l’internaute au fil des pages qu’il parcourt. Ce mode est indispensable pour gérer un panier d’achat ou conserver en mémoire que Mr Durand s’est identifié sur le site. Le langage PHP, par exemple, met en oeuvre ce type de fonctionnement en générant un cookie PHPSESSID.


Un cookie a une durée de vie paramétrable

• session : la durée de vie est limitée à la session du navigateur. Des que le navigateur est fermé, le cookie est détruit (en fait, il n’est pas détruit, il n’est plus envoyé par le navigateur, ce qui revient au même). En revanche, tant que le navigateur n’est pas fermé, il subsiste, y compris si le navigateur reste ouvert plusieurs jours.
• date fixe : le cookie sera utilisé en envoyé au serveur jusqu’à la date donnée si il n’a pas été détruit entre temps. Il n’y a pas de limite à la durée de vie paramétrée du cookie

Les usages standards sont donc

• la gestion des sessions pendant la navigation sur un site
• la mémorisation d’un choix d’utilisateur dans son navigateur (la langue d’un site par exemple ou une information de localisation géographique)
• toute information qui nécessite d’être conservée le temps qu’on quitte le site et qu’on y revienne (cas du transfert vers un prestataire de paiement par exemple)

Une limitation essentielle du cookie est qu’il est associé à un domaine et un chemin. Si le domaine est blog.grossiord.net et le chemin /, le cookie pourra être lu uniquement pas le serveur blog.grossiord.net à l’exclusion de tout autre serveur par tout chemin sur le site. Si le chemin était /test/, le cookie ne sera envoyé qu’aux pages sous /test/ et non envoyées aux pages dans /test2/. Le domaine peut être utilisé avec une wildcard *.grossiord.net, dans ce cas, il sera lisible par tous les serveurs du domaine grossiord.net (www.grossiord.net, blog.grossiord.net, etc.)

Utilisation « détournée »

La première utilisation « détournée » est effectuée par les outils de web analytics. Ils se servent des cookies pour reconstituer le parcours d’un internaute mais également faire la différence entre les nouveaux internautes et les internautes réguliers, etc.

Si l’outil de web analytics pose un cookie depuis le domaine hôte (dans le cas de ce blog, un cookie est déposé depuis le domaine blog.grossiord.net), ce cookie est dit « first part ».

Il existe par contre des outils qui posent des cookies depuis leur propre domaine, « third part », qui deviennent lisibles depuis tout site internet qui utilise cette même technologie. Cela permet de comprendre le trafic commun entre deux sites ou d’attribuer les ventes au bon apporteur de trafic dans le cas de l’affiliation.

L’utilisation de ce type de cookies peut être très puissante mais nécessite d’être faite de manière raisonnée et clairement explicitée pour protéger la vie privée des internautes.

NRJ et Spir vont commercialiser des supports « externes »

Jusqu’à présent, chacune de ces régies s’occupait de commercialiser l’espace de ses propres supports, qu’ils soient radio, journaux gratuits ou même bannières de publicité sur leurs sites web. L’enjeu pour des groupes média comme NRJ et Spir est d’être en mesure de proposer l’offre la plus complète possible en terme d’espace de publicité. En conséquence, leur métier « de base » consiste à créer de nouveaux supports en fonction de la demande des annonceurs. La partie visible se fait au niveau national : « Pour que Coca-Cola annonce chez nous, nous devons avoir une offre Ados, créons Ados FM ! » mais l’essentiel du métier de ces deux régies se joue au niveau local. Chaque commerçant, artisan cherche un support sur lequel annoncer. Les radios ont inventé les décrochages locaux pour cela, si bien que vous pouvez entendre une publicité pour la quincaillerie Marcel de la Grand Rue sur NRJ car elle est uniquement diffusée dans une ville, pendant qu’au même instant c’est le Macumba club qui annonce à l’autre bout de la France.

Or, en acceptant de commercialiser l’espace de publicité Adwords, ces deux régies traduisent le malaise dans lequel elles se trouvent depuis quelques années. Internet occupe une place de plus en plus importante comme support de communication et elles n’ont pas su créer les supports ou les réseaux sur le web qui répondent aux préoccupations de leurs annonceurs. Pour la première fois, elles vont donc commercialiser à grande échelle un support qui ne leur appartient pas.

Un enjeu de connaissance

L’élément qui va sans doute être le plus intéressant va être de constater la capacité de ces régies à commercialiser une offre aussi complexe que du Adwords. Pour rappel, l’essentiel des clients de ces régies est constitué d’artisans et de commerçant qui ne sont pas des spécialistes de la publicité en général. Alors lorsque l’on parle d’une mécanique d’enchère au mot clé qui est déjà loin d’être maitrisée par nombre de professionnels d’internet, j’ai du mal à imaginer les commerciaux terrains endosser un costume d’évangéliste. D’autant que ces derniers ne sont pas du tout des experts de la question non plus et le changement dans leur métier risque d’être (très) douloureux.

Enfin, une campagne SEM se gère, contrairement à une campagne papier qui se « booke », et là encore, dans aucun des communiqués de presse, il n’est question de l’organisation mise en place pour gérer au quotidien les budgets SEM de cette quirielle de petits annonceurs qui vont débarquer.

Google fait une jolie affaire

En récupérant ce qui lui manque : une force commerciale de terrain, Google s’intéresse de près à la « long tail » des annonceurs. On l’avait vu dans les mois passés avec les différentes initiatives de shopping local (comme Brozengo par exemple), le web de proximité se développe. Il est indéniable que cela passe par une présence terrain, qui est lourde à construire. Pour Google, s’acoquiner, probablement sans risque, avec deux acteurs ayant les commerciaux et l’habitude de la gestion decentralisée est une bonne façon de rentrer dans le sujet. Si cela fonctionne, on pourra toujours se poser la question de racheter le réseau, sinon, on aura appris ce qu’il ne faut pas faire !

Les prochains à se poser ce genre de question, et qui ont probablement déjà les projets dans les tuyaux, devraient être les Pages Jaunes et Lagardère. L’un comme l’autre disposent d’un réseau de commerciaux terrain important. Par contre, contrairement à NRJ et Spir, ils disposent l’un comme l’autre des supports et des réseaux, je serais étonné qu’ils décident de commercialiser Adwords !

Tout d’abord, l’article parle de deux sujets distincts que l’auteur confond :

1. L’efficacité de la publicité sur les réseaux sociaux pour l’annonceur
2. La pertinence des modèles économiques des réseaux sociaux

Bien sur, dans la mesure où le modèle Facebook est fortement basé sur la publicité contextuelle, l’efficacité de celle-ci est un élément important car c’est elle qui décidera d’un CPC moyen mais il ne faut pas confondre la mécanique publicitaire et le support !

L’efficacité publicitaire

Bizarrement, l’étude sur laquelle se base Francis ne dit pas tout à fait ce qu’il retranscrit. Ou plus exactement, il s’appuie sur mauvaise traduction d’une phrase « executive summary » : « moins de 5% s’en servent au moment de prendre une décision d’achat ». Dans l’article original, il est écrit « moins de 5% s’en servent régulièrement au moment de prendre… »

Si l’on s’occupe du tableau, plusieurs conclusions s’imposent

• 24% des internautes se tournent vers les média sociaux « de temps en temps » pour acheter un voyage. On peut regarder le verre à moitié vide du « seulement 4% le font régulièrement » mais il me semble que le signe est plutôt très encourageant !
• La seule « vraie » conclusion qu’on peut tirer du tableau est que les internautes utilisent plus facilement les réseaux sociaux pour des sujets « funs » (voyages, habillement, etc.) que sur des sujets graves (crédit, médicaments,etc.)

Malgré une utilisation publicitaire très jeune et sur laquelle tout est à inventer, entre 1/5 et 1/4 des internautes vont de temps en temps chercher de l’information sur les réseaux sociaux avant d’effectuer un acte d’achat. Quel échec

Cela confirme, encore une fois, que l’utilisation d’un sondage nécessite de regarder derrière les chiffres basiques. Juste pour l’exemple, je pense que la même question concernant la télévision amène un résultat bien inférieur comme medium de recommandation. Pourtant, qui pourrait dire que la publicité à la TV n’a pas d’impact sur les ventes ?

Le modèle économique

On entend régulièrement les observateurs s’inquiéter du manque de modèle de revenu de certains réseaux sociaux (y compris mon ami Jean-Michel « Les sites comme Facebook (…) génèrent peu de revenus » – JM, 300 millions de $, ça commence à faire des revenus, non ? ). Sans dire que monter une entreprise sans se soucier du business model est une bonne idée, je pense que lorsque l’on a plusieurs centaines de millions de membres qui se connectent chaque jour, le moindre centime de revenu par utilisateur se traduit en millions de dollars (je sais je suis fort en calcul).

D’autre part, je me rappelle Google il y a quelques années et le business model de la recherche sur internet. Qu’est ce qui a permis à Google de générer des milliards de dollars ?

• Un moteur de recherche exceptionnel ->une audience croissante (en nombre d’internautes) -> un nombre de recherches par jour exponentiel (Nb de requêtes x nb d’internautes)
• Un modèle de publicité innovant révolutionnaire. Alors que les autres moteurs (ou annuaires) continuaient de vendre de la bannière non ciblée au CPM, Google ne vendait que les clics sur les pages de résultat.

Les deux points sont indissociables et si aujourd’hui Facebook ou Twitter se concentrent sur l’aspect fonctionnel (le point 1), je ne pense pas que cela veuille dire que le point 2 a été oublié et qu’ils sont condamnés ! Tout reste à inventer dans la publicité en ligne (si c’est le modèle qu’ils retiennent) mais également dans les voies de générer des revenus. Et il y en a des dizaines…

Pour terminer sur une note nostalgique, en école d’ingénieur (bon, OK, c’était en 95), le directeur du département informatique avait prédit, lors du discours de bienvenue :

Internet, avec son modèle tout gratuit, n’a aucun avenir, aucune entreprise sérieuse n’acceptera de diffuser gratuitement de l’information. Dans quelques années, nous aurons reproduit le principe du 3615 pour faire payer à la connexion les internautes se connectant aux sites internet.