Link list
C’est par l’intermédiaire d’une réponse à une question écrite du député Modem Philippe Latombe que le ministère de l’Éducation Nationale officialise publiquement l’arrêt dans les établissements scolaires du déploiement ou extension de Microsoft Office 365, « ainsi que celle de Google, qui seraient contraires au RGPD ».
À l’origine, Philippe Latombe pointait dans sa question que l’offre gratuite de Microsoft « s'apparente à une forme ultime de dumping et à de la concurrence déloyale. Il semble par ailleurs qu'aucun appel d'offres n'ait eu lieu ».
Dans sa réponse, le ministère explique que les offres gratuites sont «exclues du champ de la commande publique » même s’il concède qu' « il est vraisemblable que la mise à disposition gratuite des établissements scolaires d'une suite bureautique vise à inciter un public qui aurait été accoutumé à l'utilisation de ces outils à souscrire par la suite à la version payante de son offre ». Mais il affirme avoir informé en octobre 2021 les recteurs de région académique et d'académie de la doctrine « cloud au centre » du gouvernement et des positions de la Dinum et de la CNIL sur le sujet.
Perfidement, la réponse du ministère souligne aussi que le code de l’éducation prévoit que ce sont les collectivités territoriales (les communes pour les écoles, les départements pour les collèges et les régions pour les lycées) qui doivent assurer « l'acquisition et la maintenance des infrastructures et des équipements, dont les matériels informatiques et les logiciels prévus pour leur mise en service, nécessaires à l'enseignement et aux échanges entre les membres de la communauté éducative sont à [leur] charge ».
Les applications « Messages » et « Téléphone » de Google, installées sur plus d'un milliard de smartphones, enregistrent l'activité de l'utilisateur et envoient ces données sur les serveurs de la firme. Les utilisateurs ne sont pas informés de cette collecte, qui ne respecterait pas le RGPD, et n'ont aucun moyen de s'y opposer.
Les utilisateurs d'Android sont habitués aux alertes concernant de fausses applications qui collectent leurs données. Cependant, cette fois ce sont deux applications légitimes préinstallées sur les versions récentes d'Android qui envoient des informations personnelles à Google...
Le problème a été découvert par Douglas Leith, professeur d'informatique au Trinity College de Dublin. Ce sont deux applications de Google qui sont mises en cause, à savoir Messages (com.google.android.apps.messaging) et Téléphone (com.google.android.dialer). À chaque SMS envoyé ou reçu, Messages envoie à Google un rapport qui inclut l'heure et une empreinte numérique du message. Ces données sont transmises à travers le service d'enregistrement Clearcut de Google Play ainsi que le service Firebase Analytics.
Google peut croiser les informations pour identifier l’émetteur et le destinataire
L'appli utilise la fonction de hachage SHA-256 pour créer une empreinte tronquée, ce qui est censé éviter de dévoiler le contenu du message. Toutefois, cela suffirait à Google pour faire le lien entre l'expéditeur et le destinataire. L'application Téléphone envoie des rapports similaires, avec l'heure et la durée des appels reçus ou émis. De plus, quand la protection contre les appels indésirables est activée, ce qui est le cas par défaut, l'appareil transmet également le numéro appelant aux serveurs de Google.
Graphique sur le lien entre les données collectées et l’identité réelle, via un identifiant Android, lié aux identifiants de l’appareil et de la carte SIM, ainsi qu’au compte Google, lui-même lié au numéro de téléphone et cartes bancaires. © Douglas Leith
Graphique sur le lien entre les données collectées et l’identité réelle, via un identifiant Android, lié aux identifiants de l’appareil et de la carte SIM, ainsi qu’au compte Google, lui-même lié au numéro de téléphone et cartes bancaires. © Douglas Leith
Les deux applis envoient également des informations détaillées sur leur utilisation, par exemple lorsque l'utilisateur affiche un message ou effectue une recherche dans ses conversations. Google n'informe à aucun moment l'utilisateur de la collecte de données et n'offre aucun moyen de s’y opposer. Le professeur met également en doute la conformité des applications avec le règlement général sur la protection des données (RGPD). Cette collecte ne respecterait pas les trois principes de base concernant l'anonymat, le consentement et un intérêt légitime.
Un fonctionnement particulièrement opaque
Après avoir signalé à Google ces problèmes, la firme a répondu en indiquant effectuer quelques changements. Les utilisateurs seront notifiés qu'ils utilisent une application Google avec un lien vers la politique de confidentialité. Messages ne collectera plus le numéro d'expéditeur, le code ICCID de la carte SIM, ainsi que l'empreinte des SMS. Les deux applications n'enregistreront plus les évènements liés aux appels dans Firebase Analytics. La collecte de données utilisera un identifiant temporaire plutôt que l'identifiant Android permanent. Enfin, Google informera plus explicitement les utilisateurs lorsque la fonction de protection contre les appels indésirables sera activée, et cherche actuellement comment utiliser moins d'informations ou des données plus anonymes.
Le professeur a également indiqué que Google compte ajouter à Messages une option pour refuser la collecte d’informations. Toutefois, celle-ci ne couvrirait pas ce que la firme considère comme données « essentielles ». Il s'agit d'une des premières études sur les données personnelles transmises par les services Google Play, qui restent largement opaques et pourraient cacher bien d'autres surprises...
La CNIL[1] a mis en demeure un éditeur pour avoir collecté des données à caractère personnel sur les visiteurs de son site Internet à l’aide du module Google Analytics.
En intégrant ce module Google Analytics à son site Internet, l’éditeur donnait la consigne aux navigateurs de ses visiteurs d’envoyer des informations à Google. Ces informations contenaient notamment l’adresse de la page visitée, l’éventuel page précédemment visitée (« Referer »), l’heure de la visite, l’adresse IP du visiteur et des informations sur son appareil. Ces informations pouvaient aussi contenir l’identifiant unique qui était attribué par Google à l’internaute et stocké dans un cookie et/ou l’identifiant interne que l’éditeur du site avait attribué à l’internaute, si ce dernier était connecté à son espace personnel. Le numéro de commande était aussi présent si la personne avait passé commande sur le site.
Toutes ces informations permettaient à l’éditeur de mesurer l’audience de son site Internet avec précision, mais aussi de détecter d’éventuelles erreurs et de mesurer ou d’optimiser l’efficacité ses campagnes publicitaires.
En premier lieu, la CNIL a considéré que les données collectées par ce module Google Analytics étaient des données à caractère personnel, car elles étaient associées à un identifiant unique et/ou composées de données qui pouvaient permettre d’identifier les visiteurs ou de les différencier de façon significative. La Commission a donc estimé que les exigences du RGPD[2] devaient être respectées.
Ensuite, la CNIL a rappelé que les transferts de données vers un pays n’appartenant pas à l’Union européenne étaient autorisés uniquement si « le niveau de protection des personnes physiques garanti par le [RGPD] n[’est] pas compromis »[3]. Un tel niveau de protection peut être obtenu :
si le pays de destination bénéficie d’une « décision d’adéquation »[4], c’est-à-dire une décision émanant des autorités attestation de la conformité du pays en matière de protection des données ; ou
si l’organisme de destination justifie que les mesures prises et la législation du pays permettent d’assurer un niveau de protection suffisant.Les données issues de Google Analytics sont transférées vers les États-Unis. Ce pays ne bénéficie plus d’une décision d’adéquation depuis l’arrêt[5] « Shrems II » du 16 juillet 2020 de la Cour de justice de l’Union européenne (CJUE) en raison de la surveillance de masse réalisée par les services gouvernementaux américains. Ces programmes de surveillance obligent notamment la société Google à fournir au gouvernement américain les données à caractère personnelle qu’elle possède ou les clés de chiffrement qu’elle utilise.
En l’absence d’une décision d’adéquation, l’éditeur du site et la société Google avaient recourru à des « clauses contractuelles types », c’est-à-dire un rapport détaillé justifiant un niveau de protection suffisant. La CNIL a cependant considéré, comme l’avait déjà fait la CJUE dans son arrêt cité précédemment, qu’un tel document ne permettait pas, à lui seul, d’apporter une protection contre les programmes de surveillance américain, car la société Google ne pouvait pas aller à l’encontre des lois de son pays. Des mesures additionnelles devaient donc être prises par l’éditeur et/ou Google.
Des mesures organisationnelles ont été prises par Google, comme la publication d’un rapport de transparence et la publication d’une politique de gestion des demandes d’accès gouvernementales, mais la Commission a estimé que ces mesures ne permettent pas « concrètement d’empêcher ou de réduire l’accès des services de renseignement américains ».
Des mesures techniques ont aussi été prises par Google, comme la pseudo « anonymisation »[6] des adresses IPs, mais la CNIL a estimé qu’elles « ne sont pas efficaces », car « aucune d’entre elles n’empêche les services de renseignement américain d’accéder aux données en cause ne ne rendent cet accès ineffectif ».
En l’absence d’une protection des données adéquate, la CNIL a, par conséquent, estimé que les transferts effectué par l’éditeur vers les serveurs de Google situés aux États-Unis étaient illégaux.
La CNIL a mis en demeure le site de mettre en conformité les traitements de données associés à Google Analytrics ou, si ce n’est pas possible, de retirer le module Google Analytics.
Concernant le nom de l’éditeur mis en cause, la CNIL a décidé de ne pas rendre public son nom pour des raisons que j’ignore. Il est cependant fort probable que la société soit Decathlon, Auchan ou Sephora étant donné que cette décision est la conséquence de plaintes[7] déposées par l’association militante NOYB[8].
Concernant la décision elle même, même si c’est la première fois que la CNIL prend publiquement position sur Google Analytics, ce n’est ni une surprise, ni une révolution. Depuis l’invalidation de l’accord avec les États-Unis en juillet 2020, tous les acteurs s’intéressant de près à la protection des données savent que les transferts de données vers les USA étaient, au mieux, très douteux. De plus, la CNIL n’est pas la première autorité de protection des données européenne à avoir statué dans ce sens. L’autorité autrichienne avait fait de même[9] trois mois plus tôt.
Cette décision a le mérite de mettre les choses au clair. Les organismes ne peuvent désormais plus prétendre un éventuel flou juridique. Google Analytics doit être retiré.
Notes et références
CNIL : Commission Nationale de l’Informatique et des Libertés (cnil.fr).
RGPD : Règlement Général sur la Protection des Données (Règlement (UE) 2016/679).
Le RGPD autorise des transferts de données vers des pays tiers si « le niveau de protection des personnes physiques garanti par le [RGPD] n[’est] pas compromis » (source : RGPD, article 44).
Un transfert de données à caractère vers un pays tiers peut être réalisé si une décision d’adéquation existe pour ce pays (source : RGPD, article 45). Une telle décision existe, par exemple, pour le Royaume-Uni.
La Cour de justice de l’Union européenne (CJUE) invalide le « bouclier de protection des données UE-États-Unis » dans un arrêt du 16 juillet 2020 (source : CJUE, C-311/18, 16 juillet 2020, Shrems II).
La solution Google Analytics propose une option permettant d’« anonymiser » les adresses IP des internautes. Cette opération est toutefois réalisée par Google après que le transfert de données vers les États-Unis ait lieu.
L’association NOYB a déposé des plaintes contre de nombreux organismes suite à des transferts de données personnelles vers les États-Unis jugés illicites. Six entreprises francaises sont concernées. Trois d’entre elles concernent Google Analytics : Decathlon, Auchan et Sephora (source : noyb.eu).
NOYB - European Center for Digital Rights : (noyb.eu).
L’autorité autrichienne a décidé, décembre 2021, que les transferts de données réalisés par Google Analytics étaient illicites (source : noyb.eu, en allemand) (source 2 : gdprhub.eu, en anglais).
Ce n’est pas forcément la question la plus soulevée dans la sphère SEO, mais nous voulions déterminer dans cet article si le choix de telle ou telle police web pouvait avoir un impact sur votre SEO.
Peut-être vous-êtes-vous déjà demandés si l’utilisation d’une police web personnalisée ou une Google Font, avait une incidence négative comme positive votre visibilité organique. Pour lever le voile sur ce sujet, nous avons décidé de nous replonger dans les déclarations passées de notre ami John Mueller, Webmaster Trends Analyst chez Google.
En d’autres mots, il s’agit de savoir si Google prenait en compte le choix de la police web pour juger de la qualité de votre contenu, par exemple si une police personnalisée conduisait Google à considérer le contenu comme moins pertinent que des qu’un même contenu utilisant d’autres types de web fonts.
Ce que dit Google
Cette question avait été posée à John Mueller en 2017 lors de la vidéo Webmaster Office Hours ci-dessous.
Le cadre de chez Google affirme que le choix de la police d’écriture n’a pas d’impact sur votre référencement. Du moment que Google peut explorer la page et voir le contenu, l’analyse fonctionnera normalement.
La seule situation où John indique que cela pourrait être un peu délicat est si vous utilisez des images au lieu de texte sur une page. Ok, Google fait de l’OCR (Optical Character Recognition : processus de convertir une image en texte) sur les images, mais cela reste un procédé nouveau qui n’est pas pleinement sollicité pour l’indexation des pages web (cela exige beaucoup trop de ressources).
Impact sur le temps de chargement
Le même sujet a été abordé sur Twitter en 2020. Toujours auprès de John Mueller. Cette fois-ci, la question initiale était de savoir si le choix de sa police avait un impact sur les performances de vitesse du site, puis de savoir s’il y avait des polices recommandées par Google.
Les réponses de John Mueller :
1 - Tous les éléments qui composent une page web, comme la police, ont un impact sur la vitesse de chargement.
2 - Le choix de la police n’a pas d’importance pour le SEO.
Ces deux réponses sont contradictoires puisque le temps de chargement est considéré comme un facteur de ranking SEO. Ainsi, si votre police web impacte le temps de chargement, elle influence indirectement votre SEO.
Bon ok, ce n’est pas nouveau que la police impacte le temps de chargement, c’était d’ailleurs un point majeur soulevé dans notre article sur l’optimisation de votre vitesse de site sous WordPress.
Par conséquent, si vous utilisez une police personnalisée parce que vous voulez mettre en avant votre branding, faites attention à ce que cette dernière n’impacte pas trop vos performances. Surtout avec l’introduction des Core Web Vitals en tant que facteurs de positionnement SEO.
Impact sur l’expérience utilisateur
Évidemment, si vous optez pour des polices web personnalisées totalement illisibles, cela aura un réel impact sur la compréhension qu’auront les visiteurs du contenu de votre site. Veuillez donc à ne pas trop en faire et à trouver l’équilibre entre branding et expérience de navigation.
Mais améliorer l’expérience utilisateur signifie aussi que chaque milliseconde compte. De ce fait, il existe de nombreuses façons d’améliorer la vitesse, comme l’optimisation des images et des polices de caractères web.
Commençons par une note positive : il est facile d’adopter une belle typographie gratuitement pour votre site comme vous pouvez en trouver dans les magazines papier. Des sociétés comme Fontawesome, Google et Adobe proposent énormément de polices gratuites qui vous permettront de construire votre site selon votre image. Cependant, un grand nombre auront impact drastique sur la vitesse de vos pages… pouvant vous faire perdre de précieuses secondes et chuter votre score sur PageSpeed Insights.
Voyons donc ensemble comment ces satanés polices web peuvent autant impacter votre temps de chargement en se focalisant sur les polices Google.
Le problème des polices Google
Les Google Fonts peuvent représenter plusieurs problèmes pour vos performances de site. Mais pas que…
Combien de requêtes HTTP les polices effectuent-elles ?
Lorsque votre site est en train de charger sur un navigateur, vous avez peut-être remarqué des messages dans la barre d’état tels que « connecting to fonts.gstatic.com » ou « waiting for fonts.googleapis.com ». Il s’agit du navigateur qui télécharge la police sur laquelle votre site repose à partir de serveurs qui hébergent ces polices.
Pour analyser ce processus de plus près, il suffit de se rendre sur des sites de mesure de vitesse de page tels que GTmetrix ou Pingdom et de tester votre URL. Il y a de fortes chances que vous soyez surpris par le nombre de requêtes que votre site nécessite pour télécharger des fichiers de polices. Mais… attendez deux p’tites secondes… ces polices ne sont-elles pas transférées à partir d’un Google Cloud super méga rapide ?!!
Existe-t-il un CDN pour les polices ?
Oui, les polices web sont fournies par le CDN de Google. Google a optimisé et continue d’optimiser ces fichiers pour un transfert plus rapide. Néanmoins, il s’agit de demandes supplémentaires de données supplémentaires dont la plupart des sites et blogs peuvent se passer. Les néo webmasters commencent souvent avec un hébergement mutualisé chez OVH, et souvent avec un ensemble de plugins redondants qui alourdissent les performances globales de leur site. Dans la plupart des cas, les fichiers de polices web ne font que s’ajouter à la masse.
Quel est le poids des polices web ?
La taille typique d’un fichier de police est de 35-50ko. Cependant, selon la façon dont votre site est développé, il peut nécessiter plusieurs fichiers de polices ou parfois, même un seul fichier de police peut atteindre un poids de quelques mégaoctets. Cela s’explique par le fait qu’un site peut utiliser plus d’une langue, nécessiter plusieurs formats de fichiers ou devoir être disponible en mode hors ligne. Parfois, les thèmes et les plugins qui utilisent les Google Web Fonts font plusieurs demandes pour la même ressource. Pire encore, votre site peut obliger un visiteur à télécharger des éléments qui ne sont jamais utilisés. La plupart du temps, les visiteurs de votre site peuvent se passer de tout cela.
Du coup, une question légitime que l’on pourrait se poser serait de savoir si la mise en cache avait un impact ? Un navigateur ne va-t-il pas stocker ces polices pour une utilisation ultérieure ? La réponse courte : pas tout.
Quid de la mise en cache des polices Google ?
La mise en cache du navigateur ne permet d’accélérer que les visites répétées, et non les premières visites. Pour les visiteurs réguliers, le webmaster du site a le pouvoir de définir la durée pendant laquelle le navigateur doit mettre en cache une ressource localement. Vous pouvez fixer une date d’expiration lointaine (d’un mois ou plus) pour les ressources statiques telles que les images, etc… mais pas pour tout ! En effet, pour les ressources fournies par des tiers, comme Facebook ou Google, le propriétaire du site n’a aucun contrôle. Leur date d’expiration est fixée par les sites qui les fournissent.
Alors que les fichiers de polices de base peuvent avoir une date d’expiration lointaine, les ressources de style liées aux polices ont une date d’expiration de seulement 24h00 en général. Ainsi, lorsqu’un fichier de police a été modifié et qu’un abonné email clique sur le lien d’une newsletter pour lire votre dernier article, ce visiteur fidèle devra télécharger à nouveau toute la police web requise. Inutile de dire que si votre abonné dispose d’une connexion internet pourrie, vous ne l’aidez pas.
Alors, pourquoi ne pas simplement fournir les polices à partir de votre site et de contrôler l’expiration du cache du navigateur ?
Peut-on charger les polices Google en local ?
Les polices web étant OpenSource, vous pouvez les héberger localement sur votre site, réduire le nombre de requêtes HTTP et contrôler l’expiration du cache. Il existe des plugins gratuits pour vous aider à y parvenir. Toutefois, Google déconseille cette pratique. Cela m’amène à poser la question suivante : pourquoi Google adopterait-il une pratique aussi gourmande en termes de ressources, puis déconseillerait dans le même temps une solution permettant de consommer moins et d’optimiser les performances ?
La raison officielle invoquée par la firme de Mountain View est qu’il héberge et fournit les polices afin que vous ayez les plus récentes et les plus optimisées à disposition pour votre site web. Cependant, la vérité se cache peut-être ailleurs…
Les polices Google portent-elles atteinte à la vie privée ?
Quelques pays, comme la Chine, bloquent l’accès à aux serveurs Google, ce qui signifie que les sites utilisant les Google Fonts n’auront pas la même apparence partout dans le monde. De nombreuses autres personnes ont fait part de leurs inquiétudes quant à la confidentialité des données liées aux polices Google, en particulier dans le sillage de la mise en œuvre de la politique européenne RGPD. En effet, en fournissant la police de votre site, Google a un accès direct à ses entrailles. Pour vous faire une idée, jetez un œil à la quantité gargantuesque de données collectées par Google à travers ses polices en consultant les statistiques du site Google Font Analytics.
Les Google Fonts seront-elles toujours gratuites ?
Les polices web représentent un pilier essentiel pour le secteur des éditeurs. La capture à grande échelle des données d’utilisation de ses polices peut potentiellement aider Google à créer un modèle freemium classant les polices gratuites et premium afin de convaincre les navigateurs (tels que Firefox, Safari ou Internet Explorer) d’inclure certaines de ces polices en tant qu’option native dans leurs futures versions. Autre possibilité, l’API Google Fonts pourrait suivre le chemin de l’API de Google Maps, qui exige désormais des propriétaires de sites qu’ils fournissent des informations de carte bancaire pour pouvoir l’utiliser.
Google propose Google Fonts : des polices d’écritures à utiliser pour votre site web, dans le CSS.
Seulement ils sont bien malin : le code CSS prêt-à-utiliser que vous devez mettre dans votre code contient le lien du fichier de la police d’écriture qui se trouve sur leur serveur. Voilà la marche à suivre pour récupérer manuellement le fichier et le placer en local, chez vous.
Je vais faire l’exemple avec une police d’écriture au hasard.
Rendez-vous sur google.com/fonts. Choisissez la police que vous voulez, puis cliquez sur « quick-use » :
Descendez un peu en bas dans la page et récupérez le lien vers le fichier CSS :
Ouvrez ce lien dans votre navigateur.
Vous pouvez déjà copier tout le code dans votre CSS. Il suffit juste de récupérer le lien vers le fichier de la police (fichier .woff).
Téléchargez le fichier .woff et enregistrez le dans votre projet.
Il ne reste alors plus qu’à changer le lien de la police dans le code CSS, pour qu’il utilise le fichier .woff local et pas via le site de Google.
Voilà, c’est tout.
L’avantage d’avoir le fichier de la police chez soi :
Pas de traçage possible par Google
Votre site reste indépendant : si Google ferme son service (il le fera un jour) votre CSS fonctionnera quand même.Désavantages :
Le fichier de la police sera téléchargé depuis votre site, donc consommera votre bande passante.
Si un autre site web quelque part utilise la même police, le navigateur le téléchargera deux fois, alors qu’il ne le fait qu’une seule fois si les deux utilisent le service de Google.
Cette astuce s’inscrit dans ma politique d’un site 100% indépendant sur le plan technique. Il n’y a aucun fichier (image, script…) utilisé dans mes pages qui soit hébergé ailleurs que chez moi.