A lire sur www.commentreparer.com : Durée de vie des produits : qui a envie de l’obsolescence programmée ?

Vous souhaitez développer les liens pour votre campagne de référencement mais trouver les bons sites où vous référencer vous prend trop de temps ? Vous avez défini quelques dizaines de mots-clés et vous aimeriez tester toutes les combinaisons de blogs/annuaire/site web/actualités ou vidéo sur ce thème. Et vous aimeriez bien avoir les 50 ou 100 meilleurs résultats sur toutes ces combinaisons de mots-clés.

Oui, mais vous n’avez pas le temps de lancer 4000 requêtes à la main, une par une. Et puis Excel commence à atteindre ses limites pour trier et classer les 400000 sites qu’elles renvoient. Pas facile de regrouper les sites par domaine, de trouver les concurrents, de prioriser les plus importants ou de connaître leurs principales métriques. Et puis vous aimeriez envoyer des demandes de liens personnalisés (par e-mail, par formulaire) ou commenter sur les blogs en gardant une trace de toutes les demandes, mais là aussi c’est vite chronophage.

Vous avez besoin d’un outil de linkbuilding qui prend en charge tout le processus de recherche, de qualification et de suivi des liens. C’est à cela que sert LinkBuilder.

Actuellement en bêta privée, cet outil a pour but de vous faire gagner du temps dans votre création de liens.

En complément, obtenez des conseils sur le référencement et le netlinking sur mon blog référencement.

LinkBuilder : l’application de recherche de liens

Sur un site institutionnel mis à jour peu fréquemment (une fois par jour) et à trafic modéré, la méthode classique de vidage complet du cache ($cache->clean()) peut être employée. Pendant les minutes qui suivent, les visiteurs du site subiront quelques ralentissements, le temps que le cache se reconstitue.

Mais sur un site participatif où les internautes publient des contenus des dizaines de fois par jour, cette méthode simple atteint ses limites. Pour améliorer les performances du cache, il devient important d’être sélectif dans l’invalidation des pages, en se restreignant uniquement à celles qui sont affectées par le changement. C’est ici qu’intervient le système de tags de Zend_Cache.

Les tags

Il est possible d’associer des tags spécifiques à chacune des pages ou urls définies dans le cache. On pourra ensuite supprimer, au moment de la mise à jour, uniquement les pages concernées. Supposons que vous ayez une page d’accueil listant des actus ainsi que les dernières questions d’utilisateurs, un moteur de recherche de questions, et des pages d’articles HTML qui changent rarement. Lorsqu’un utilisateur ajoute une question, on voudra mettre à jour l’accueil et les pages de résultats du moteur de recherche, mais pas les pages HTML. On définira donc des tags appropriés à chaque sous forme d’un tableau associatif, dans la déclaration des regexp :

$frontendOptions = array(

    // Options de base du cache de page,

    // Liste des pages avec leurs tags
    'regexps' => array(

        '^/$' => array(
            'cache' => true,
            'specific_lifetime' => 3600,
            'tags' => array('index','questions','actus')
            ),

        '^/reparations/liste' => array(
            'cache' => true,
            'tags' => array('questions')),

        '^/pages' => array(
            'cache' => true,
            'tags' => array('pages')),

        '^/[0-9]+/.*' => array(
            'cache' => true,
            'tags' => array('questions')
            )
    )
);

Lors de la mise à jour d’une fiche, on appellera, juste après avoir enregistré les modifications dans la base de données, la méthode de vidage du cache pour chaque tag :

// On sauve une question en BDD
// On suppose que le cache a été instancié dans le bootstrap
// et est accessible dans la variable App::$cache
App::$cache->clean(Zend_Cache::CLEANING_MODE_MATCHING_TAG, 'index');
App::$cache->clean(Zend_Cache::CLEANING_MODE_MATCHING_TAG, 'liste');

Un cache plus sélectif ?

Vous pourrez, à juste titre, trouver que ce système d’invalidation de cache reste très approximatif. Après tout, si notre site comporte 100000 questions, remettre à jour le tag questions va purger tous ces contenus d’un coup, ce qui n’est pas très efficace. Je ne crois pas que Zend_Cache propose un système plus précis via les Regexp, mais on peut ruser en segmentant à la main ses enregistrements. Par exemple, vous pouvez parfaitement créer une règle qui concerne toutes les questions dont l’identifiant se termine par le chiffre 1, et lui affecter le tag question_1, puis ceux qui terminent par 2 auront question_2, etc. jusqu’à 0. En regexp, on aura quelque chose comme ça (à tester) :

'regexps' => array(
    '^/[0-9]*1/.*' => array(
        'cache' => true,
        'tags' => array('questions_1')
    ),
    '^/[0-9]*2/.*' => array(
        'cache' => true,
        'tags' => array('questions_2')
    ),
    etc.
);

Lorsqu’on voudra invalider le cache après avoir mis à jour ou créé une question, on pourra donc appeler la fonction clean() avec le tag correspondant au dernier chiffre de l’identifiant de cette question. Ainsi à chaque mise à jour, on ne touchera qu’à 1/10^ème des caches. Mais on peut aller encore plus loin : il y a peut-être une limite au nombre de regexps des Frontends Zend, mais je pense qu’on peut sans problème utiliser les 2 derniers chiffres en itérant de 00 à 99 (en traitant séparément les enregistrements de 1 à 9) avec une boucle for qui ajoute des lignes au tableau regexps et génère les tags appropriés :

$regexps = array(

    // Pages de base

);

for ($i = 0; $i <= 99; $i++)
{

    if (strlen($i) == 1)
    {
        $regexps[] = array(
            '^/' . $i . '/.*' => array(
                'cache' => true,
                'tags' => array('questions_' . $i)
            )
        );

    }
    $ids = str_pad($i, 2, '0', STR_PAD_LEFT);

    $regexps[] = array(
        '^/[0-9]*' . $ids . '/.*' => array(
            'cache' => true,
            'tags' => array('questions_' . $ids)
        )
    );
)

Les plus aventureux pourraient même tester un regexp à 3 chiffres, ou pourquoi pas couvrir l’intégralité des identifiants de la base (1 à 5000, 1 à 10000 ?), mais à partir d’une certaine taille le chargement du cache risque de devenir coûteux en ressources mémoire et CPU. Il faut trouver le bon compromis pour avoir un rechargement assez régulier mais sans trop multiplier les tags.

Le cas des codes Google Analytics/Google Adsense

Si vous utilisez des cookies pour authentifier des utilisateurs et que vous voulez bénéficier du cache, vous souhaitez probablement que chaque utilisateur ait une page en cache adaptée à son profil (compte, informations personnelles, contenus personnalisés, etc.). Dans ce cas vous activerez l’option cache_with_cookies_variables et make_id_with_cookie_variables du Frontend. Malheureusement, les scripts Google Analytics et Google Adsense génèrent leurs propres cookies pour TOUS les utilisateurs, ce qui fait que le cache est régénéré même pour les utilisateurs non authentifiés (qui devraient tous avoir le même contenu sur une url donnée). Pire, ces cookies changent de valeur à chaque rechargement de page, si bien que le cache est invalidé à chaque fois.

Un blog a identifié ce problème et propose une solution que j’ai adaptée : créer une classe Frontend_Page personnalisée qui ne tient pas compte des cookies Google. Cette classe hérite de Zend_Cache_Frontend_Cache et redéfinit uniquement la méthode _makePartialId() qui boucle sur les différentes variables pour créer un identifiant unique. Il suffit d’éliminer les Cookies commençant par un double underscore (__utmz, __utma, etc.) pour qu’ils ne soient pas pris en compte dans la création de l’identifiant unique :

// Partie à modifier dans la méthode _makePartialId()
case 'Cookie':
    if (isset($_COOKIE)) {
     $my_cookie = $_COOKIE;
     foreach($my_cookie as $key=>$val){
        // remove google analytics cookie
        if(false !== strpos($key,"__")){
            unset($my_cookie[$key]);
        }

     }
     $var = $my_cookie;
    } else {
      $var = null;
    }
    break;

Conclusion

En dépit de ces limitations, le cache de pages est un outil pratique, car il couvre l'ensemble d'un site sans nécessiter de s'intercaler dans chacun des contrôleurs de l'application (sauf lors de l'invalidation, bien sûr). On lui pardonnera donc son côté un peu trop radical. Pour un travail d'orfèvre (cache par page, par requête SQL), on pourra lui préférer d'autres Frontends comme Zend_Cache_Frontend_Output ou Zend_Cache_Core. Mais il faudra le déployer partout dans l'application, en plus de définir les tags, ce qui est plus laborieux. A vous de voir.

Code complet

Dans le bootstrap (class App) :

class App {

    public $cache;

    // functions d'instanciation du MVC, DB, etc.

    /**
    * Active le cache de pages
    *
    */
    public function usePageCache()
    {

        $debug_cache = true; // Activé en développement, pas en production
        $frontendOptions = array(
            'lifetime' => 86400,
            'cache_id_prefix' => 'cr_',
            'automatic_serialization' => true,
            'debug_header' => $debug_cache,
            'automatic_cleaning_factor' => 100, // Une fois sur 100, il vide les caches obsolètes automatiquement

            // On désactive le cache par défaut, on le réactivera plus tard par Regexp
            'default_options' => array(
                'cache' => false,
                'cache_with_get_variables' => true,
                'cache_with_post_variables' => false,
                'cache_with_session_variables' => true,
                'cache_with_files_variables' => false,
                'cache_with_cookie_variables' => true, // Uniquement si vous voulez cacher les pages des utilisateurs loggés
                'make_id_with_get_variables' => true,
                'make_id_with_post_variables' => true,
                'make_id_with_session_variables' => true,
                'make_id_with_files_variables' => true,
                'make_id_with_cookie_variables' => true,// Pour les utilisateurs loggés

            ),
            // On ne cache que les pages correspondant aux URL ci-dessous
            'regexps' => array(

                '^/$' => array(
                    'cache' => true,
                    'specific_lifetime' => 3600,
                    'tags' => array('index','questions','actus')
                    ),

                '^/reparations/liste' => array(
                    'cache' => true,
                    'tags' => array('questions')),

                '^/pages' => array(
                    'cache' => true,
                    'tags' => array('pages')),

                '^/[0-9]+/.*' => array(
                    'cache' => true,
                    'tags' => array('questions')
                    )
            )
        );
        $backendOptions = array(
            'cache_dir' => ROOT_PATH . '/tmp'
        );

        $front = new My_CacheFrontendPageGA($frontendOptions);
        App::$cache = Zend_Cache::factory(
            $front,
            'File',
            $frontendOptions,
            $backendOptions
        );

        App::$cache->start();

    /**
    * Vide le cache : intégralement ou selon une liste de tags
    *
    * @param array $tags
    */
    function viderCache($tags = null)
    {
        if (is_array($tags))
        {
            foreach ($tags as $tag)
            {
                $tag = array($tag);
                App::$cache->clean(Zend_Cache::CLEANING_MODE_MATCHING_TAG, $tag);
            }
        }
        else
        {
            App::$cache->clean();
        }
    }

Fichier de classe library/My/CacheFrontendPageGA.php

<?php
class My_CacheFrontendPageGA extends Zend_Cache_Frontend_Page {

    /**
     * Make a partial id depending on options
     *
     * @param  string $arrayName Superglobal array name
     * @param  bool   $bool1     If true, cache is still on even if there are some variables in the superglobal array
     * @param  bool   $bool2     If true, we have to use the content of the superglobal array to make a partial id
     * @return mixed|false Partial id (string) or false if the cache should have not to be used
    */
    protected function _makePartialId($arrayName, $bool1, $bool2)
    {
        switch ($arrayName) {
        case 'Get':
            $var = $_GET;
            break;
        case 'Post':
            $var = $_POST;
            break;
        case 'Session':
            if (isset($_SESSION)) {
                $var = $_SESSION;
            } else {
                $var = null;
            }
            break;
        case 'Cookie':
            if (isset($_COOKIE)) {
              $my_cookie = $_COOKIE;
              foreach($my_cookie as $key=>$val){
                 // remove google analytics cookie
                 if(false !== strpos($key,"__")){
                     unset($my_cookie[$key]);
                 }

              }
              $var = $my_cookie;
           } else {
               $var = null;
           }
           break;
        case 'Files':
            $var = $_FILES;
            break;
        default:
            return false;
        }
        if ($bool1) {
            if ($bool2) {
                return serialize($var);
            }
            return '';
        }
        if (count($var) > 0) {
            return false;
        }
        return '';
    }

}

Ce cahier des charges était plutôt léger sur les spécifications fonctionnelles (le listing des fonctionnalités), et j’indiquais aux lecteurs qu’ils pouvaient me solliciter pour obtenir un exemple de tableau de fonctionnalités à intégrer en annexe.

Deux internautes m’ayant demandé ce document cette semaine, j’ai réalisé un modèle-type de liste de fonctionnalités pour un site d’e-commerce que je vous propose en téléchargement :

Il s’agit évidemment d’exemples génériques à compléter en fonction de vos besoins réels.

Une fois rempli par vos soins ce tableau pourra être remis au prestataire chargé de la création du site qui devra répondre à chaque ligne s’il peut le faire « en standard », « en option » (prix à spécifier à part dans son devis) ou si c’est impossible.

Le mieux est de ne mettre qu’une seule fonctionnalité par ligne : évitez par exemple de placer sur une ligne « des actualités triées par catégories et par auteur, contenant des vidéos avec une page d’archives, reprises en une du site » car la réponse que vous obtiendrez ne sera pas forcément facile à décoder.

N’hésitez pas à suggérer des améliorations dans les commentaires. Et si vous cherchez une solution de référencement pour votre site, c’est ici.

Et si vous tentiez de le réparer ? Sur CommentReparer.com, demandez un coup de main et, avec un peu de chance, vous prolongerez la durée de vie de votre matériel de quelques mois ou années, pour une poignée euros.

Sans compter que vous éviterez un double gâchis écologique (les déchets de votre ancien matériel, la production et le transport du nouveau). Alors c’est sûr, ça ne marche pas à tous les coups, mais ça ne coûte rien d’essayer !

Le site : CommentReparer.com

La première fois dans un magasin bio, tu restes au moins cinq bonnes minutes devant chaque produit, avec des interrogations devant l’étiquette, du genre « ah ouais, cette brioche coûte quand même quatre fois plus cher que celle que j’achète d’habitude », ou « comment ça, il n’y a pas de vin à moins de 6,50 euros ??? ». Tu te reposes, à chaque item de ta liste, la question essentielle : « est-ce que j’en ai vraiment besoin ? ». Et tu te mets à regarder en tout petit le prix au kilo pour trouver le conditionnement le plus rentable sur la durée. Tu finis par éliminer certains produits de luxe deux à trois fois plus chers, pour te rabattre sur les valeurs sûres : oublie la confiture de figues qui te fait envie, ce sera FRAISES, 1 KILO, POINT.

Pour un enfant, on pourrait croire que c’est plus facile puisqu’il se fout de prendre les produits les plus chers, et bien non. Mon gamin de cinq ans, sommé de choisir un petit déj aux rayons idoines (pâtisseries, biscuits, céréales), a subi des tourments bien plus grands encore. Pensez donc : sans marketing outrancier (ou alors mauvais, petits moyens obligent), il ne trouva point de mascotte sur l’emballage pour aiguiller son choix. Et comment il fait le petit consommateur quand il a pas un tigre sympa ou un bonhomme rigolo sur le paquet ? Quand il a pas d’autocollants Beyblade, de magnets Transformers, de figurine Dora ou de livret Charlotte aux Fraises qui le décide à choisir un produit plutôt qu’un autre ? Ben il fait comme nous, bien obligé : il réfléchit.

Il voit les produits en vrai dans leur emballage transparent, pas sur une photo retouchée aux couleurs saturées qui rend ultra-désirables des aliments tout à fait insipides. Il doit imaginer leur goût et, c’est le plus dur, se demander ce qu’il aime.

Bien sûr, la première fois, il a rusé, en se rattachant à du connu : il a choisi la seule boîte sous carton qui montrait en photo d’alléchantes madeleines dégoulinantes de confiture d’abricot (en fait sèches et friables et même pas bio, l’arnaque) qu’il n’a pas mangées. Mais la semaine suivante, il a bien regardé les céréales, vu celles au miel qui lui faisaient envie, et opté pour ces dernières malgré un packaging réduit à sa plus simple expression. Ben du coup, il les a toutes mangées, et il en a repris dès qu’il les a eues finies. Goût = 1, Marketing = 0.

Le sevrage est en cours, pour notre fils et nous, et nous avons bien l’intention d’aller jusqu’au bout. Car au delà de la désintoxication du marketing, c’est surtout sa sensibilité au goût des aliments qu’on veut développer. [Mode Jean-Pierre Coffe ON] Nan parce que quand même, il y a tellement de trucs bons à manger que c’est dommage de se laisser refiler de la merde, même bien emballée. Il faut apprendre à se débarrasser de certains réflexes de facilité. Le goût, ça se mérite.[Mode Jean-Pierre Coffe OFF]

Alors faites l’expérience, sortez au moins une fois vos charmants bambins dans une boutique bio et observez-les choisir. Et commencez la cure de désintox…

Voir le site SMILF

Pour ceux qui prétendraient ne pas connaître le mot MILF, il s’agit d’une abréviation pour Mother I’d Like to F..k, soit en français correct « une mère de famille digne d’éloge ».

Quant à Sushi Man, c’est le nom tout aussi exotique des cuisiniers japonais chargés de la fabrication des sushis.

Je ne sais par quel glissement langagier ces deux sujets apparemment non miscibles en sont venus à se télescoper, mais voilà le résultat. Etonnant, non ?

Mettons nous en situation

Dans mon cas, j’ai souvent l’habitude d’appeler un objet depuis un autre. Par exemple, j’appelle l’objet Magazine associé à un Article par la méthode $article->getMagazine(). C’est pratique, ça permet des enchassements de méthodes assez rigolos genre $article->getMagazine()->getCouverture()->getUrl(). Jusqu’ici, pas de problème : il suffit d’écrire la méthode getMagazine() dans ma classe Article héritant de Zend_Db_Table_Row, et les autres méthodes dans les autres classes.

Mais que se passe-t-il si j’appelle huit fois de suite la méthode getMagazine() ? Il instanciera bêtement l’objet magazine huit fois de suite, avec huit requêtes SQL successives. Pas très optimal question performances. J’aimerais donc stocker l’objet Magazine, une fois instancié, dans une variable de la classe Article, et lui ressortir l’objet stocké les sept fois suivantes. Et là, ça coince.

Les limites de Zend_Db_Table_Row

Une classe héritant de Zend_Db_Table_Row possède un nombre défini de propriétés accessibles, qui correspondent rigoureusement aux colonnes de la table SQL associée. Si vous tentez, naïvement, de définir une nouvelle variable du type $magazine->variable1 = 50, il génère une erreur car il n’est pas prévu de pouvoir lui associer d’autres variables que celles de sa table.

Comment contourner cette limite ? J’ai trouvé la réponse sur le forum du Zend Framework :

• créer une nouvelle classe héritant de Zend_Db_Table_Row, par exemple My_DbTableRow
• créer dans cette classe une variable $_otherData qui contiendra les variables customisées. Ce tableau s’ajoute aux tableaux associatifs $_data et $_cleanData utilisés par la classe pour stocker les colonnes de la table
• surcharger les méthodes accesseurs (__get(), __set(), __isset() et __unset()) de l’objet Zend_Db_Table_Row pour qu’il vérifie si une variable donnée existe dans le tableau $_otherData en plus du tableau $_data

Mais l’auteur ne livrait pas le code correspondant, j’ai donc suivi ses recommandations et je vous livre ci-dessous le code de ma classe :

<?php
class My_DbTableRow extends Zend_Db_Table_Row_Abstract
{
    protected $_otherData = array();

    function __set($var, $value)
    {
        if (in_array($var,$this->getTable()->info('cols')))
        {
            parent::__set($var, $value);
        }
        else
        {
            $this->_otherData[$var] = $value;
        }
    }

    function __get($var)
    {
        if (isset($this->_data[$var]))
        {
            return parent::__get($var);;
        }
        else
        {
            return $this->_otherData[$var] ;
        }
    }

    function __isset($var)
    {
        if (isset($this->_otherData[$var]))
        {
            return true;
        }
        else
        {
            return parent::__isset($var);
        }
    }

    function __unset($var)
    {
        if (isset($this->_otherData[$var]))
        {
            unset ($this->_otherData[$var]);
        }
        else
        {
            parent::__unset($var);
        }
    }
}

Au passage, j’ajoute ma classe My_DbTable qui étend la classe Zend_Db_Table_Row en utilisant par défaut le nouvel objet My_DbTableRow « extensible ».

Usage

Avec ces classes, vous pouvez donc créer des objets Zend_Db_Table_Row « extensibles » et leur affecter à l’exécution des nouvelles variables qui n’existent pas dans la table. Attention, vous ne pourrez évidemment pas sauver ces propriétés dans la base de données.

Pour revenir à mon exemple de code initial, voici comment je pourrais écrire mon code :

// Fichier Articles.php
class Articles extends My_DbTable {
    protected $_rowClass = 'Article';
}

class Article extends My_DbTableRow {
    function getMagazine()
    {
        // On vérifie si une variable a déjà été définie avec le même nom que la fonction et on l'instancie si besoin
        if (!isset($this->getMagazine))
        {
            // On peut utiliser la méthode magique find*() si on a défini
            // les relations entre les tables $this->findMagazines();
            $this->getMagazine = // code pour instancer le magazine
        }
        return $this->getMagazine;
    }
}

Ainsi lorsque j’appellerai la méthode $article->getMagazine(), il n’instanciera qu’une seule fois l’objet magazine, et me renverra le contenu de la variable getMagazine les fois suivantes.

N’hésitez pas à me signaler toute erreur ou suggestion d’amélioration.

Précisons que je suis un très mauvais commercial, que je ne « rentre » de budgets que par mes amis et connaissances immédiates et que je préfère travailler pour des bonnes causes et des indépendants en démarrage d’activité, c’est à dire que l’argent ne coule pas à flot. Mais je m’en fous parce que j’ai déjà un travail à plein temps qui nourrit ma famille. Bref.

En réalisant mes premiers logos, j’ai constaté un piège dans la manière dont j’abordais le chiffrage des devis : je m’étais fixé une échelle mentale du genre « je veux gagner 50 euros de l’heure / un logo pour une petite boîte demande 6 heures de travail / je facture 300 euros ». Et puis j’ai eu des demandes d’amis qui n’avaient pas un rond, pour qui j’ai fait un devis à 60 euros (net d’impôt). La dernière fois, j’avais l’impression de brader mon boulot, jusqu’à ce que je trouve, après une petite heure de travail, quelques « pistes » présentables à affiner, que je proposai à cet ami pour « orienter » le travail. Quelle ne fut pas ma surprise lorsqu’il valida, sans plus de discours, l’une des pistes proposées. Pas de changement de typo, pas d’essais de couleur. Il a dit : « c’est magnifique, je prends la 1f ». C’était décidé.

En lui envoyant son logo, je calculai rapidement qu’il m’avait payé proportionnellement plus cher qu’un client pour qui j’aurais consacré six heures de travail ou dix ou vingt, parce qu’il m’aurait demandé d’autres pistes, des corrections de détail, des retouches quasi invisibles, avant de revenir à la première version… En résumé, ce client « facile » était beaucoup plus rentable qu’un client un peu plus cher mais casse-bonbons.

Dans mon boulot de tous les jours, j’ai déjà constaté ce contraste, où l’on rencontre un jour des bons payeurs qui alignent 30000 euros et qui te laissent travailler parce qu’il te font entièrement confiance alors que celui qui t’a filé 500 euros à contrecoeur va te rappeler dix fois par jour parce qu’il n’est pas satisfait de la couleur d’un pixel ou de la justification du texte.

D’où l’idée suivante : ne devrait-on pas faire payer le client en fonction de son potentiel de casse-pieds ? Les ceux qui disent toujours « oui, c’est super, merci » paieraient pas cher, et les relous jamais contents paieraient plein pot. Je sais me direz-vous, ça existe, ça s’appelle « faire payer les heures réelles » mais le client n’en veut pas parce qu’il a l’impression (parfois légitime) que le prestataire va en profiter pour faire traîner le boulot.

Non, j’aimerais bien trouver une méthode pour « sentir » le poisson avant de le ferrer, avant de lui donner un prix. Peut-être qu’il s’agit juste d’instinct ou d’expérience, et qu’avec le temps j’arriverai à le faire sans même m’en rendre compte. Peut-être qu’il y a des manières de procéder qui permettraient de le savoir en amont. J’en ai deux qui me viennent à l’esprit :

• avant de signer un gros projet, démarrer un petit projet « pas cher » (et pas long), voire carrément offert, et tâter le terrain. Par exemple, avant de réaliser un site à 3000 euros, s’accorder pour lui faire un logo et étudier la relation qui se met en place.
• contractualiser le nombre d’allers-retours sous forme d’options : si tu veux 10 propositions de logos avec possibilité de revenir dessus 6 fois, tu paies 3000 ; si tu acceptes de choisir parmi une liste de 3 propositions et que tu as droit à une seule variation après ça, tu paies 300.

J’imagine que je ne suis pas le seul à m’être posé la question et à rêver de séparer le bon grain de l’ivraie. Et vous les entrepreneurs, vous faites comment ?

• le manque-à-gagner en publicité pour ces deux mois, si l’on se base aux statistiques des mois précédents, se monte à environ 7 euros (pour rappel, j’avais un CPM assez faiblard, et environ 5000 visites par mois)
• j’ai récupéré du temps que je passais à surveiller les taux de clics Adsense qui vivotaient laborieusement, je le passe désormais à des activités plus « enrichissantes » : lire et répondre aux commentaires, par exemple.
• mon blog a généré environ 250 visites vers mon activité de création de sites web. Sur ces visites, j’ai reçu une demande de devis crédible pour la refonte graphique de 2 blogs.
• l’article sur Adsense a lui-même pas mal buzzé (là, là ou là), et m’a valu un déjeuner avec un lecteur qui avait un projet à me proposer. Pas rémunérateur mais intéressant.

Conclusions provisoires et possibilités futures

Côté argent :

Dans l’absolu, je n’ai pas touché un seul centime, c’est vrai. Néammoins ces deux prospects me paraissent un premier pas encourageant.

Comment l’évaluer financièrement ? Si on veut se lancer dans des calculs statistiques (un peu à l’arrache), on peut dire qu’un devis rapporte le coût moyen d’une prestation multiplié par le pourcentage de devis qui se concrétisent réellement. Etant débutant (et sélectif) en matière de prospection commerciale, je vais partir sur des valeurs faibles : 300 euros de prestation pour 10% de signatures. Le calcul est vite fait : 300×10% = 30 euros. C’est de l’argent virtuel, mais l’argent de Google est tout aussi virtuel tant qu’on n’a pas atteint le seuil de versement.

N’empêche, je ne me baserais pas sur un tel chiffre pour évaluer définitivement le potentiel d’un site, en particulier parce qu’il repose sur UN seul devis et qu’il pourrait bien se passer six mois sans demande, ce qui ramènerait la moyenne proche de zéro (à noter que sur la même période, Adwords m’a apporté 10 demandes de devis pour un investissement de 30 euros, ce qui est déjà plus régulier et permet d’en tirer des grands enseignements).

Côté référencement :

Un autre élément à prendre en compte est le référencement naturel. Au contraire des publicités (type Adwords) qui n’impactent la fréquentation de mon site que pendant que j’alimente le compte, les liens que je crée entre mon blog et mon site pro sont de la bonne matière à SEO. Du coup je peux espérer, d’ici quelques mois, que le trafic en provenance de Google s’améliore lentement mais sûrement, et ce sans y injecter d’argent.

Côté relation avec les visiteurs :

Lorsqu’un visiteur prend la peine de regarder une pub sur un blog, sa relation avec vous est soit totalement superficielle (il arrive, il clique, il t’oublie), soit carrément hostile (« la pub c’est le mal ! »). Bref, humainement, la pub est loin de créer une situation relationnelle idéale.

Au contraire, passer plus de temps sur les commentaires m’apporte déjà une interaction plus riche qu’auparavant. Quand c’est une demande de devis par formulaire, cela peut déboucher sur des collaborations intéressantes. Quand cela se concrétise sous forme de rendez-vous physique, c’est le jackpot. J’ai enfin l’impression que tout ce déballage d’idées, de retours d’expérience, d’interrogations que constitue un blog avait réellement une utilité : débattre, être impliqué dans des projets, être (un peu) reconnu.

Conclusion

Bref, je suis d’ores et déjà satisfait de ce changement. Le calcul financier gagne à être affiné mais les 7 euros de Google Adsense ne me manquent pas. A bon entendeur !