lalahop

Utiliser l’API de Piwik pour générer des rapports

Table des matières

L'API de Piwik permet, entre autres, de générer des rapports automatiques et/ou personnalisables.

Rappels de base sur l'API

L'API peut être interrogée via HTTP ou être utilisée directement dans vos scripts PHP. Voir ici pour des exemples : Piwik Analytics API – Calling Techniques. Ci-dessous, nous intégrerons l'API à un script PHP mais il est tout à fait envisageable de scripter l'appel à l'API via HTTP grâce à un script shell et à curl/wget. Quand on a compris une méthode, l'autre coule de source, seul le formalisme change.

Si je n'ai qu'un seul reproche à formuler à l'API, c'est son manque de documentation. Les prototypes des fonctions disponibles sont bien annoncés mais on ne nous explique pas toujours ce que la fonction attend en paramètre. Il faut alors aller lire le code source pour comprendre. De plus, l’hétérogénéité (ou le manque d'harmonisation) du code n'aide pas (ex. : pour certaines fonctions, on doit passer un tableau, pour d'autres une liste dont les termes sont séparés par une virgule ...).

Comment créer un rapport depuis l'API ?

Pourquoi créer un rapport via l'API alors que l'interface web le permet ? Parfois, la création d'un rapport via l'interface web échoue. Je n'ai pas encore cherché la cause du problème.

Voici le code :

<?php

	define('PIWIK_INCLUDE_PATH', realpath('./piwik')); //Répertoire racine de Piwik
	define('PIWIK_USER_PATH', realpath('./piwik')); //Idem
	define('PIWIK_ENABLE_DISPATCH', false);
	define('PIWIK_ENABLE_ERROR_HANDLER', false);
	define('PIWIK_ENABLE_SESSION_START', false);
	require_once PIWIK_INCLUDE_PATH . "/index.php";
	require_once PIWIK_INCLUDE_PATH . "/core/API/Request.php";
 
        //On créer le contrôleur
	Piwik_FrontController::getInstance()->init();
 
        //On prépare la requête que l'on souhaite effectuer
	$request = new Piwik_API_Request('
			method=PDFReports.addReport
			&idSite=1
			&description=test API
			&period=never
			&reportFormat=html
                        &reports=VisitsSummary_get,VisitTime_getVisitInformationPerLocalTime,Actions_getPageTitles,Actions_getOutlinks,Referers_getRefererType,Referers_getKeywords,Referers_getWebsites,Referers_getSearchEngines,UserCountry_getCountry,VisitorInterest_getNumberOfVisitsPerVisitDuration,VisitorInterest_getNumberOfVisitsPerPage,VisitFrequency_get,Provider_getProvider,UserSettings_getConfiguration
			&emailMe=0
			&token_auth=votretoken
	');

 
        //On exécute la requête
        $result = $request->process();
 
        //On affiche le résultat de la requête
	echo $result,'<br />';
?>

La méthode Piwik_API_Request permet de préparer une requête pour l'API. Les paramètres de cette méthode sont variables selon ce que l'on veut obtenir. Ici (seuls les paramètres peu ou pas documentés sont expliquées) :

  • method permet de spécifier ce que l'on veut obtenir. Ici, nous utilisons la méthode addReports du module PDFReports. Pour avoir une idée des opérations disponibles, il suffit d'aller dans la doc de Piwik (j'ai déjà donné un lien plus haut)
  • description permet de spécifier la description du rapport (voir interface web)
  • reportFormat permet de choisir un format de rapport (pdf ou html)
  • reports permet de choisir les informations (configuration matérielle du visiteur, heure de visite, ...) que l'on veut intégrer au rapport. La liste est disponible en appelant la méthode getReportMetadata du module API. Voir un exemple en ligne. Il suffit de récupérer l'uniqueId associé au rapport que vous voulez et de l'indiquer dans ce paramètre. Ici, on récupère, dans l'ordre : le récapitulatif des visites, les visites en fonction de l'heure locale, le titre des pages vues, les liens sortants, les types de referer (entrée directe, site web, ...), les mots clés dans les moteurs de recherche, les sites web, les moteurs de recherches d'où provient l'entrée, le pays du visiteur, la durée d'une visite, le nombre de pages par visite, la fréquence des visites, le FAI, la configuration complète du visiteur.
  • emailMe permet de demander la réception du rapport par courrier. Ici, on refuse (0).

Si la création du rapport fonctionne, l'API vous retourne l'id du rapport, sinon, l'API vous retourne un message d'erreur explicite.

Comment générer un rapport automatiquement depuis un script ?

Si vous avez compris l'exemple précédent, rien de bien compliqué ici : il suffit de lire la doc et les fichiers sources.

<?php
	define('PIWIK_INCLUDE_PATH', realpath('./piwik')); //Répertoire racine de Piwik
	define('PIWIK_USER_PATH', realpath('./piwik')); //Idem
	define('PIWIK_ENABLE_DISPATCH', false);
	define('PIWIK_ENABLE_ERROR_HANDLER', false);
	define('PIWIK_ENABLE_SESSION_START', false);
	require_once PIWIK_INCLUDE_PATH . "/index.php";
	require_once PIWIK_INCLUDE_PATH . "/core/API/Request.php";

        //On créer le contrôleur
	Piwik_FrontController::getInstance()->init();
        //On prépare la requête que l'on souhaite effectuer
	$request = new Piwik_API_Request('
			method=PDFReports.generateReport
			&idSite=1
			&idReport=2
			&date=2011-07-05
			&language=fr
			&period=month
			&reportFormat=html
			&outputType=2
			&token_auth=votretoken
        ');

 
        //On exécute la requête
        $result = $request->process();
?>

Explications :

  • idReport doit correspondre à l'id d'un rapport existant. Cet id est retourné par la méthode addReport ou est disponible dans la base de données et plus précisément dans la table prefixe_pdf. En remplaçant "prefixe" par le préfixe de vos tables Piwik.
  • outputType correspond à la manière dont le rapport sera sauvegardé. Si la valeur 1 est passée, alors le fichier sera disponible en téléchargement. Si la valeur 2 est passée, alors le fichier sera stocké sur le serveur, dans le repertoire piwik/tmp/assets/ . La valeur 1 est la valeur par défaut. Ces deux valeurs sont définies dans les constantes OUTPUT_DOWNLOAD et OUTPUT_SAVE_ON_DISK de la classe Piwik_PDFReports_API (fichier Piwik/plugins/PDFReports/API.php.

Là où cela devient intéressant, c'est dans le cadre d'un processus de sauvegarde secondaire. En effet, si vous n'avez jamais exporté vos données sur une longue période, il est fastidieux de le faire à la main.

L'API possède une option YYYY-MM-DD,YYYY-MM-DD pour le paramètre date et une option "month" pour le paramètre period. Cela permet donc de récupérer, comme le dit la doc, des informations pour chaque mois de la période donnée. Ex. : index.php?module=API&method=VisitsSummary.get&idSite=1&period=month&date=2010-07-01,2011-03-01&format=html permet de récupérer le récapitulatif des visiteurs pour chacun des mois compris entre juillet 2010 et mars 2011, au format html. Mais, cela ne fonctionne pas avec toutes les méthodes de l'API. C'est notamment le cas avec le module live ou le module PDFReports.

Il va donc falloir scripter afin de récupérer un rapport par mois, tous les mois d'une période donnée. Une simple boucle et l'utilisation de la classe DateTime suffiront. Cela donne :

<?php
	define('PIWIK_INCLUDE_PATH', realpath('./piwik')); //Répertoire racine de Piwik
	define('PIWIK_USER_PATH', realpath('./piwik')); //Idem
	define('PIWIK_ENABLE_DISPATCH', false);
	define('PIWIK_ENABLE_ERROR_HANDLER', false);
	define('PIWIK_ENABLE_SESSION_START', false);
	require_once PIWIK_INCLUDE_PATH . "/index.php";
	require_once PIWIK_INCLUDE_PATH . "/core/API/Request.php";
 
        //On créer le contrôleur
	Piwik_FrontController::getInstance()->init();
 
        //On prépare la période sur laquelle on va travailler
	$dateDebut = '2010-08-01';
	$dateFin = '2011-08-01';	
	$dateInc = new DateTime($dateDebut);

 
        //Tant que la date qui va être incrémenté n'est pas égale à la date de fin ...
	while ($dateInc->format('Y-m-d') != $dateFin)
	{	
                // ... on prépare la requête ...

	        $request = new Piwik_API_Request('
				method=PDFReports.generateReport
				&idSite=1
				&idReport=1
				&date='.$dateInc->format('Y-m-d').'
				&language=fr
				&period=month
				&reportFormat=html
				&outputType=2
				&token_auth=votretoken
		');

 
		// ... et on l’exécute ...
		$result = $request->process();
 
                // ... et enfin on incrémente la date sur laquelle on travaille		
		$dateInc->modify('+1 month');
	}
?>

ÉDIT 31/07/2011 à 1h12 :
Le script ci-dessus peut-être optimisé. Nous profitons de l'opérateur d'égalité (pas d'identité !) qui permet de faire la différence entre deux objets d'une même classe en fonction de la valeur de leur attributs. Ainsi, nous ne faisons plus appel à la méthode "format()" de la classe DateTime. Ce qui donne :

        // code identique
        $dateDebut = new DateTime('2010-08-01');
        $dateFin = new DateTime('2011-08-01');	
 
        //Tant que la date qui va être incrémenté n'est pas égale à la date de fin ...
	while ($dateDebut != $dateFin)
	{
		// code identique
	}

Côté performance, cela est insignifiant : environ 0.0012 secondes d'écart entre les deux scripts, en faveur du deuxième script. Mesure effectuée avec la fonction xdebug_time_index() de XDebug, en ne faisant rien d'autre qu'afficher un message avec echo dans la boucle while et en prenant une période de 490 mois .
Fin de l'édit

Comment débloquer la limite du nombre de lignes de chaque tableau ?

Comme je l'ai déjà dit, dans un rapport, le nombre de lignes par tableau est limité (ex. : seulement les 30 mots-clés les plus utilisés sont affichés).

L'API précise qu'il existe un paramètre optionnel, filter_truncate, qui permet de changer cette limite. Néanmoins, ce paramètre est contourné par le module PDFReports. C'est dans le fichier /piwik/plugins/PDFReports/API.php que cela se passe :

Lignes 313-314 :

$filterTruncateGET = Piwik_Common::getRequestVar('filter_truncate', false);
$_GET['filter_truncate'] = 30;

Lignes 333-337 :

// Restore values
if($filterTruncateGET !== false)
{
        $_GET['filter_truncate'] = $filterTruncateGET;
}

Bien que cette option a sans doute été désactivée pour des raisons de performances, il y a un moyen de la réactiver :

Il suffit de remplacer les lignes 313/314 par :

$_GET['filter_truncate'] = $filterTruncateGET = Piwik_Common::getRequestVar('filter_truncate', false);

Et de commenter les lignes 333-337.

Ensuite, vous pouvez utiliser filter_truncate. Avec ce code, les tableaux du rapport généré feront jusqu'à 100 lignes. Ainsi, dans le rapport sur les mots-clés utilisés, vous aurez le top 100 au lieu du top 30 :

$request = new Piwik_API_Request('
		method=PDFReports.generateReport
		&idSite=1
		&idReport=1
		&date='.$dateInc->format('Y-m-d').'
		&language=fr
		&period=month
		&reportFormat=html
		&outputType=2
                &filter_truncate=100
		&token_auth=votretoken
');

Comment utiliser l'API pour générer des rapports plus personnels

De nombreuses méthodes existent dans l'API Piwik. Cela vous permet de vous fabriquer un rapport sur mesure (avec uniquement les informations que vous voulez) ou de surveiller une seule information (le nombre de visiteurs uniques du mois, par exemple). De plus, l'API donne accès à des informations que les rapports n’intègrent pas (ex. : le module live n'apparait pas dans les rapports), ce qui permet un export des données.

C'est ici que je vous laisse car vous trouverez des exemples dans la documentation de Piwik.

PS : Les codes donnés ci-dessus n'ont pas vocation à être utilisés en production sans amélioration. Par exemple : il n'y a pas de contrôle des erreurs.

PS2 : Ce billet n'évoque pas la Piwik Tracker API. Il peut tout de même être intéressant de jeter un oeil à la documentation, pour, par exemple, prendre un minimum en compte les utilisateurs ayant désactivé javascript.

De la bonne sauvegarde de ses applications web

Table des matières

Dans ce billet, je vais vous parler de la sauvegarde de vos applications web (site classique, CMS, ...). Évidemment, je ne vais pas parler de tous les cas et vous devriez donc adapter ce billet à votre situation. Ce billet a plus vocation à expliquer la méthodologie à mettre en place plutôt que l'exhaustivité des situations. Je ne parlerai pas des motivations qui peuvent vous amener à réaliser des sauvegardes ou des principes de base d'une bonne sauvegarde (régulière, garantissant l'intégrité des données, ...) car c'est du vu et revu.

Sauvegarde des fichiers

La première chose à faire est de sauvegarder les fichiers de votre application. Le protocole est au choix : FTP, FTPs, SCP, ... Il convient de se demander ce qu'il faut sauvegarder. En effet, si dans le cas d'une application @home (= personnelle), il convient de garder l'intégralité de l'arborescence, ce n'est pas nécessaire avec un CMS utilisant une base de données, par exemple. Exemple : pour WordPress, seul le dossier wp-content/uploads est important. Le reste (plugins, thème, reste des fichiers) peut facilement être récupéré et réinstallé.

Si jamais votre application web stocke ses données dans des fichiers, je vous conseille, dans un souci de cohérence des données sauvegardées, de bloquer l'accès à l'application durant la sauvegarde. Un fichier .htaccess placé à la racine de votre application web avec ce contenu devrait suffire :

Deny from all

Note : Non, je ne pense pas que bloquer l'accès à votre site personnel durant 2 minutes vous soit dommageable, surtout si vous le faites dans le créneau horaire où vous avez le moins de visiteurs. Après, pour les grosses applications/applications professionnelles, on peut discuter de ce principe.

Sauvegarde de la base de données

Si votre application utilise une base de données, il convient évidemment d'en exporter les données. Là encore, les méthodes sont nombreuses selon l’accès que vous avez au serveur : commande (mysqldump, pg_dump, ...) ou application web (phpmyadmin, phpPgAdmin, ...), etc..

Là encore, je vous conseille de bloquer l'accès à l'application durant la sauvegarde.

Voici les paramètres que j'utilise avec phpmyadmin (cela peut-être adapté à la commande mysqldump sans aucune difficulté) :
On vérifie que toutes les tables sont sélectionnées. On vérifie que le mode de sauvegarde est bien SQL. On vérifie que les rubriques "Structure" et "Données" sont bien cochées afin d'exporter l'intégralité des données.

Enclose export in a transaction // Utiliser le mode transactionnel : utilise le principe des transactions : si la sauvegarde se termine alors elle sera complète, sinon elle ne vous sera pas proposée. C'est un mode "tout ou rien". Je pense que c'est une sécurité et qu'il vaut mieux l'activer.

Disable foreign key checks // Désactiver la vérification des clés étrangères : évidemment, on laisse cette option désactivée ... dois-je vraiment expliquer pourquoi ?

Add DROP TABLE / DROP VIEW // Ajouter DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT : permet, lors de la restauration, de supprimer la table et la récréer si elle existe encore dans la base. Cette option est une bonne idée et devrait être cochée. Cela garantit que des anciennes données (sauvegarde) ne seront pas mélangées avec les nouvelles données. On obtient donc une garantie de cohérence des données. Si la sauvegarde commence à dater, il est par contre évident que l'on perd beaucoup de données. Mais une sauvegarde doit être régulière donc ce problème ne se pose pas ;).

Add IF NOT EXISTS // Ajouter IF NOT EXISTS : Si elle n'est pas présente et qu'une table porte le même nom lors de la restauration, vous aurez une erreur "Table already exists" et rien ne sera fait. Si elle est présente et qu'une table porte le même nom, vous n'aurez pas l’erreur précédente car le script n'essayera pas de recréer la table mais vous aurez une erreur en rapport avec les index lors de l'insertion des données dans la table ("Duplicate entry 'Dodo-1' for key 'PRIMARY' "). Et là, rien ne vous dit que des données n'ont pas été insérées avant que le SGBD ne rencontre une clé identique et vous en informe. Bref, cette option n'est pas une bonne idée.

Complete inserts ou Extended inserts // Insertions complètes ou Insertions étendues : il convient d'activer les deux. Voir pourquoi ici.

Use delayed inserts // Insertions avec délais : cette option n'est pas une bonne idée. Elle permet de mettre en queue les insert si la table est déjà utilisée. Une bonne restauration doit se faire offline pour éviter toute perte de données/incohérence donc nous n'avons pas besoin de cette option.

Use ignore inserts // Ignorer les erreurs de doublons : cette option n'est pas non plus une bonne idée : si des doublons existent au niveau des indexes, il vaut mieux en être informé que d'ignorer leur présence (même s’il valait mieux découvrir leur présence avant de faire une restauration post-crash, je suis d'accord :P).

Export type // Type d'exportation : insert. Update suppose que les données soient présentes, ce qui n'est pas le cas après un crash et replace peut insérer des incohérences entre plusieurs tables dans le cas où on restaure qu'une seule table, par exemple. Le mieux reste donc l'option DROP + Insert.

Le reste des options n'a pas d'importance : on peut choisir d'exporter les triggers, les vues, etc., et on laissera le reste des options sur leurs valeurs par défaut : nous avons réglé l'essentiel.

On vérifie que la case "Save as file" // "Transmettre" est cochée. On choisit également un mode de compression.

On lance la sauvegarde.

Sauvegarde du contenu "en clair"

Il me paraît important de sauvegarder les données de l'application web au format texte brut (ou autre format humainement lisible, libre et ouvert pour les données non représentables textuellement) quand cela est possible. Cela permet d'une part, d'être plus indépendant de l'application web utilisée qu'un script de conversion qu'il faudra créé lorsque l'on voudra changer de CMS, par exemple. D'autre part, cela permet d'avoir une sauvegarde humainement compréhensible dans le cas où la sauvegarde principale ne fonctionne plus (je pense notamment à un dump SQL refusant d'être restauré).

Cette sauvegarde devrait être réalisée à la main plutôt que par un logiciel/extension. Je vous rappelle, en effet, qu'un logiciel est forcement buggé (ou insuffisamment testé).

En cas de crash complet, il faudra réinjecter les données à la main dans l'application quand c'est possible et nécessaire (cas des billets d'un blog) ou bien garder ces sauvegardes en souvenir (cas des stats d'un site).

Évidemment, tout cela n'est pas toujours possible selon le volume de données, leur nature, ...

Je vais néanmoins vous donner deux exemples :

WordPress

Le plus important ici, c'est bien évidemment les billets que vous avez publié, voire les commentaires de vos visiteurs.

Pour conserver vos billets, il suffit de créer un bête fichier texte ayant une structure comme celle-ci, par exemple :
Titre :
Auteur (si plusieurs posteurs) :
Date de publication :
Catégories :
Mots-clés :
Contenu :

Il suffit ensuite de remplir ce modèle avec les données issues de l'administration de WordPress et plus précisément de la page vous permettant de modifier les billets. Pensez à sauvegarder les balises HTML, tout quoi.

Pour conserver les commentaires de vos visiteurs, il suffit de créer un bête fichier texte ayant une structure comme celle-ci, par exemple :
Auteur :
Email :
Site Web :
Date :
Contenu :

Il suffit ensuite de remplir ce modèle avec les données issues de l'administration de WordPress et plus précisément de la page vous permettant de modérer les commentaires.

Si les commentaires vous tiennent à cœur et que vous avez un blog à fort trafic, vous pouvez toujours envisager l'écriture d'un script ...

Piwik

Ici, le plus important, c'est les statistiques. Un plugin, PDFReports, permet la création de rapports au format PDF ou HTML. Il peut même vous l'envoyer par mail à une fréquence déterminée.

Si vous n'avez pas sauvegardé vos statistiques et que vous avez installé Piwik il y a peu de temps

Vous pouvez envisager d'utiliser PDFReports. Cliquez sur le lien "Rapports e-mail" dans le header de l’interface web de Piwik. Dans le calendrier, choisissez la période à exporter. Cliquez ensuite sur le lien "Créer et planifier un rapport". Saisissez une description de la sauvegarde. Choisissez "Jamais" dans la liste déroulante "Planification courriel" et décochez "Envoyer à moi". Choisissez HTML comme format du rapport. Choisissez les données que vous souhaitez exporter. Enfin, cliquez sur le bouton "Mettre à jour le rapport". Cliquez sur "Télécharger" pour récupérer le rapport.

Maintenant, pour chaque période que vous souhaitez sauvegarder, cliquez sur le calendrier, choisissez la période et cliquez sur "Télécharger".

Note : Si, quand vous cliquez sur le bouton "Mettre à jour", une ligne "Chargement des données" apparaît mais ne disparait pas ou si votre rapport n'apparait pas dans la liste, pendez à actualiser la page (F5) : ceci est probablement dû à un problème avec le cache.

Néanmoins, les rapports ont une quantité limitée de données (ex. : les 30 derniers mots-clés). Si vous souhaitez outrepasser cela (il faut néanmoins se poser la question de la pertinence de la sauvegarde de ces données supplémentaires vis-à-vis du poids qu'elles vont occuper), regarder ci-dessous.

Si vous n'avez pas sauvegardé vos statistiques et que vous avez installé Piwik il y a longtemps

Il faut utiliser l'API de Piwik pour générer, de manière automatique, un rapport pour une période donnée. Vous pouvez également débloquer la limite de lignes dans chaque rubrique du rapport comme expliqué ci-dessus. Enfin, dans le cas où la création du rapport est impossible depuis l'interface web (je n'ai pas compris pourquoi cela bug chez certains hébergeurs), l'API permet de créer un rapport.

Ces cas d'utilisation sont évoqués, pour plus de clarté, dans un autre billet : Utiliser l’API de Piwik pour générer des rapports

Essayer ses sauvegardes

N'oubliez pas de toujours essayer vos sauvegardes. Si vous avez sauvegardé votre base de données, essayez de la restaurer dans une autre base, si vous avez sauvegardé vos fichiers, essayez-les sur un autre serveur. Ce n'est pas compliqué de se monter un serveur de test local (pour ceux qui n'en ont pas encore et qui effectuent leurs modifications directement sur le serveur de production) : il y a le moyen artisanal (tout installer et configurer à la mano) ou utiliser des logiciels qui font tout à votre place (ex. : WampServer).

Enfin n'oubliez pas :

  • Faites un plan de sauvegarde de vos applications web qui leur correspondent. Il est vain d'appliquer bêtement un modèle donné sans réfléchir aux données que l'on doit sauvegarder.
  • Les sauvegardes, c'est comme le sexe chez les adolescents 😉

Tuto4pc: Le nouveau cheval de Troie d’eoRezo

Les tutoriels, ce n'est pas nouveau. CCM et le Site du Zéro en font depuis de nombreuse années. Des tonnes.

Comment faire du fric rapidement ? Simple ! Publiez des tutoriels assaisonnés d'adware/spyware ! C'est facile et pas très fatiguant:

  • Écrivez quelques tutoriels (c'est à la portée de beaucoup de monde)
  • Allez chercher quelques éditeurs d'adware et spywares (eoRezo et autres).
  • Mélangez, secouez
  • Profitez !

C'est le modèle de Tuto4pc. Et le PDG trouve que ce business-modèle est "innovant". Woao... des spywares dans des tutoriels, putain, c'est révolutionnaire. Ça vaut bien l'introduction en bourse.

Attendez, le plus beau c'est le contrat d'utilisation (J'espère que vous avez l'anus en béton armé pour consulter ces tutoriels):

LES INFORMATIONS COMMUNIQUEES PAR LES UTILISATEURS SERONT CONSERVEES DANS UN FICHIER INFORMATISE APPARTENANT A LA SOCIETE TUTO4PC ET SONT SUSCEPTIBLES D'ETRE COMMUNIQUEES AUX PARTENAIRES COMMERCIAUX DE TUTO4PC, ET/OU A TOUT TIERS

Donc toutes les infos que vous donnez à tuto4pc seront vendus à d'autres entreprises. Attendez, ce n'est pas fini:

L’UTILISATEUR ACCEPTE DE RECEVOIR DE L'TUTO4PC ET/OU DE SES PARTENAIRES DES OFFRES COMMERCIALES SUR SON TELEPHONE PORTABLE PAR SMS OU MMS.

Vous allez donc être pourri de SMS de publicité.

Les dits composants peuvent faire apparaître, sur l'écran de l'Utilisateur, des messages publicitaires ou autres informations de la part d'TUTO4PC ou d’annonceurs tiers

Votre PC aussi.

L’Utilisateur accepte que les services proposés par TUTO4PC associés aux logiciels téléchargés et en particulier les Logiciels TUTO4PC, puissent modifier les paramètres de navigateur WEB (bookmark, page d'accueil, onglet).

En prime, ils vont détourner la page d'accueil de votre navigateur (avec lo.st), bidouiller vos bookmarks et onglets.

TUTO4PC peut être amené à recueillir des informations concernant les adresses des sites internet préalablement visités par l'internaute.

Ils vont piocher allègrement dans votre historique de navigation.

L'Utilisateur autorise les mises à jour et/ou les installations automatiques des Logiciels TUTO4PC et de tout logiciel de sociétés tierces accessibles par l'intermédiaire de TUTO4PC.

Autrement dit TUTO4PC vend votre PC à d'autres sociétés qui pourront installer ce qu'elles veulent dessus. Installez un tutoriel, et vendez votre âme.

Les dits composants restent actifs à tout moment afin de contrôler et d'assurer la fourniture du service de TUTO4PC, et d'autres fonctions telles que celles décrites dans le présent paragraphe.

D'autres fonctions "telles que", mais pas que celles-là ? Lesquelles ?

La responsabilité vis-à-vis de l'utilisateur en matière d'utilisation ou d'utilisation incorrecte des Logiciels TUTO4PC ou d'un logiciel de société tierce accessible par l'intermédiaire des Logiciels TUTO4PC ne saurait en aucun cas être attribuée à TUTO4PC ou à ladite société tierce.
[...]
TUTO4PC et toute société tierce permettant l'accès à son logiciel par l'intermédiaire des Logiciels TUTO4PC n'acceptent aucune responsabilité en ce qui concerne les dommages susceptibles de résulter du téléchargement et/ou de l'utilisation des Logiciels TUTO4PC et/ou de tout logiciel de société tierce accessible par l'intermédiaire des Logiciels TUTO4PC.

Traduction: Si les logiciels installés par Tuto4PC ou ses partenaires vont foutre la merde sur internet, c'est pour votre gueule, c'est vous le responsable.

La société TUTO4PC tranchera souverainement tout litige relatif à l'interprétation du présent règlement. Il ne sera répondu à aucune demande téléphonique concernant l'interprétation ou application du présent règlement.

Une question sur le contrat ? Une contestation ? Allez vous faire foutre. C'est nous qu'on dit comment ça se passe.

Tout ça... pour des tutoriels ? Ils se foutent de notre gueule ?

J'ai regardé le tutoriel Photoshop sur le château dans les nuages, ça ne casse pas 3 pattes à un canard. C'est un bête masque entre deux images.

Franck ROSSET, Président Directeur Général... de quoi ? La société Tuto4PC mentionnée dans le contrat précédent n'existe pas. TutoGroup non plus. Aucune trace dans le registre des sociétés françaises (ou alors j'ai mal cherché). D'ailleurs il n'y a aucun numéro de SIRET sur leur site web. En grattant un peu, on voit que le domaine est domicilié au 14 rue Lincoln, 75008 Paris. Et devinez qui on trouve à la même adresse ? eoRezo, grand pourvoyeur d'adware/spyware ! En fait, tuto4pc n'est qu'un prétexte: C'est qu'une nouvelle voie que cherche eoRezo pour atteindre plus d'ordinateurs. Ils le disent eux-même.

Quand je vois tout le travail fait sur CCM, le SDZ ou les dizaines d'autres sites communautaires depuis plus de 10 ans et les tonnes de tutoriels gratuits sans contrepartie, le modèle économique de tuto4pc me fait gerber. Non pas que je reproche aux gens de gagner de l'argent en écrivant des tutoriels. Pas du tout. Mais carotter l'ordinateur des internautes avec des spyware et piller leur vie privée pour gagner de l'argent, ça c'est minable.

Maintenant on pourra rétorquer que les internautes qui installent ces merdes ont accepté le contrat d'utilisation en toute connaissance de cause, mais personne n'est dupe.

Et non, ce n'est PAS INNOVANT.

(Un grand Merci à Ludovic pour m'avoir donné l'info.)

-------------------------------------------------------------------------------------------

Explications :