Pas la peine de lancer certbot tous les jours… Le lancer une fois par semaine est bien suffisant.
Qui plus est il est aussi préferrable de ne pas le lancer à minuit pile mais de décaler un peu.
Letsencrypt est une organisation à but non lucratif qui fournit un service gratuit. La moindre des choses que l'on puisse faire est de miniser son propre impact sur eux. Donc éviter de trop les solliciter et éviter de le faire tous en même temps.
Très clairement, tu es plus calé que moi sur le sujet! L'objectif n'est absolument pas de toucher des personnes comme toi dans cet article, je te désinforme plus que autres choses.
L'objectif est de faire découvrir à tous les développeurs et autres fonctionnels les implications (assez grossièrement) de cette nouvelle réglementation.
Merci pour ton retour intéressant !
Alors pourquoi avoir parlé de “droit à l'oubli” ? Il n'existe pas sinon cité entre guillemets. On te parle de “droit à l'effacement”, ce qui est un chouilla différent.
Par contre, le particulier peut demander la restitution d'une partie des données, celles que tu as donné, tu peux demander l'effacement de ton identité pour les services non essentiels, et à la fin des traitements usuels (délais de garde, garantie, expiration de droits, etc), ces données nominatives doivent disparaitre.
(EDIT : j'oubliais de signaler qu'une empreinte digitale, une image de caméra de vidéosurveillance, l'IP d'un ADSL ou un SSID d'un smartphone est une donnée identifiante, donc personnelle. Et on a déjà une première précision dans le RGPD qui précise qu'une telle donnée ne peut être marchandée. Exeunt donc les filtres anti-anti-adware des journaux ou l'obligation de donner son numéro de plaque minéralogique pour se garer).
Or, il se trouve que ces dispositions existaient déjà dans la loi française et les normes du traitement documentaire. Je le sais d'autant mieux que j'ai bossé sur une GED avec une formation spécifique sur ces normes.
Sur la gestion d'un fichier avec données nominatives, il “suffit” pour un développeur de se calquer sur les procédures de gestion documentaire, qui stipulent qu'une donnée récoltée doit être décrite, avoir une finalité précise, une traçabilité, et des process, notamment les conditions d'accès aux données.
Car oui, dans le RGPD, si tu le relis très attentivement, on te demande de documenter des procédures et les flux de données. Oui, je sais, écrire de la doc, c'est toujours bien moins sexy que faire du TDD ou jongler avec ses images dockers… Mais cela t'oblige à réfléchir à 2 fois sur par exemple ton presta de newsletter ou le service d'OCR en PaaS.
C'est la raison pour laquelle tu es responsable du choix de ton sous-traitant, et que ce dernier doit t'informer de toute modification dans le process concernant tes données, notamment le recours à sa propre sous-traitance ou la localisation (grossière) de ses serveurs de backups.
(EDIT: j'avais oublié aussi de préciser qu'il y a un process qui est demandé en cas de découverte d'une faille de sécurité. Comme répondre à ces questions : Pourquoi a-t-elle eu lieue ? Comment a-t-elle lieue ? Qu'avez-vous fait pour la limiter dans l'immédiat ? Avez vous les logs d'accès ? Qui a profité de cette faille ? Qui est impacté par les données disséminées ? Que comptez-vous faire pour qu'elle ne se reproduise pas ?. Encore une fois, documenter et que des bonnes pratiques)
Après, il y a de très nombreuses subtilités qui existent déjà dans le droit, mais sont désormais normalisées au niveau Européen ; Comme, par exemple que les coordonnées d'une entreprise uni-personnelle doivent être vues comme celles d'un particulier. Eh oui, ben ça, ça date des premières jurisprudences de la loi de 1978.
Et on ne limite pas uniquement aux données commerciales : les salariés sont eux-aussi concernés.
D'ailleurs, plutôt que prôner l'effacement, ce qui cause de nombreux autres soucis comme la cohérence de ta base, il vaut mieux recourir à la pseudonymisation, donc utiliser des tables, voire des bases différenciées.
Je suis désolé de ma tartine, mais… La loi c'est comme le code : l'imprécision peut se payer cher
J'ai pris le temps de faire un article orienté pour les DEVELOPPEURS, pour leur donner une idée des implications de cette réglementation. Comment un article de 1300 mots pourrait-ils prétendre résumer l'implémentation de la GDPR qui est composer d'une centaine de pages ?
Il s'agit bien évidement de vulgarisation et par conséquent il y a des raccourcis dans l'article. Bien sûr que les données nécessaires aux obligations légales ne peuvent être supprimées (par exemple)…. Je l'explique d'ailleurs dans un des paragraphes plus bas. Je t'invite avec (grand) plaisir à faire un commentaire plus constructif, je l’intégrerai volontiers au sein de l'article.
«Chaque utilisateur ayant un droit à l’oubli, il est nécessaire de prévoir une fonction qui supprime l’ensemble des données personnelles de cet utilisateur.»
Alors NON: cela dépend très très fortement de l'intérêt du consommateur, et des autres obligations légales. Écrire ça comme ça décrédibilise totalement le reste de l'article.
Je suis aussi très content de cet outil que j'ai découvert il y a quelques mois ! Je l'ai utilisé dans l'équipe RabbitMQ pour tester nos packages sur tout plein d'OS, y compris Windows : Terraform nous permet de déployer une vingtaine de VMs, lancer le test d'un snapshot de RabbitMQ sur chacune, et enfin détruire les VMs. Ça a remplacé Docker qui ne correspondait pas du tout au cas d'utilisation.
beaucoup d'aspects commerciaux aussi, ça n'est jamais une bonne publicité (plutôt le contraire d'ailleurs) de perdre un client comme la mairie de Munich ou de Barcelone.
Le problème de Munin <troll>outre le fait que ce soit du Perl</troll> c'est qu'il te spam de notifications en cas de problème, pas moyen d'être notifié uniquement lors du changement d'état, ou au moins d'espacer les notifications dans le temps sans espacer les checks eux-mêmes.
Pas la peine de lancer certbot tous les jours… Le lancer une fois par semaine est bien suffisant. Qui plus est il est aussi préferrable de ne pas le lancer à minuit pile mais de décaler un peu.
Letsencrypt est une organisation à but non lucratif qui fournit un service gratuit. La moindre des choses que l'on puisse faire est de miniser son propre impact sur eux. Donc éviter de trop les solliciter et éviter de le faire tous en même temps.
Très clairement, tu es plus calé que moi sur le sujet! L'objectif n'est absolument pas de toucher des personnes comme toi dans cet article, je te désinforme plus que autres choses. L'objectif est de faire découvrir à tous les développeurs et autres fonctionnels les implications (assez grossièrement) de cette nouvelle réglementation. Merci pour ton retour intéressant !
Alors pourquoi avoir parlé de “droit à l'oubli” ? Il n'existe pas sinon cité entre guillemets. On te parle de “droit à l'effacement”, ce qui est un chouilla différent. Par contre, le particulier peut demander la restitution d'une partie des données, celles que tu as donné, tu peux demander l'effacement de ton identité pour les services non essentiels, et à la fin des traitements usuels (délais de garde, garantie, expiration de droits, etc), ces données nominatives doivent disparaitre.
(EDIT : j'oubliais de signaler qu'une empreinte digitale, une image de caméra de vidéosurveillance, l'IP d'un ADSL ou un SSID d'un smartphone est une donnée identifiante, donc personnelle. Et on a déjà une première précision dans le RGPD qui précise qu'une telle donnée ne peut être marchandée. Exeunt donc les filtres anti-anti-adware des journaux ou l'obligation de donner son numéro de plaque minéralogique pour se garer).
Or, il se trouve que ces dispositions existaient déjà dans la loi française et les normes du traitement documentaire. Je le sais d'autant mieux que j'ai bossé sur une GED avec une formation spécifique sur ces normes.
Sur la gestion d'un fichier avec données nominatives, il “suffit” pour un développeur de se calquer sur les procédures de gestion documentaire, qui stipulent qu'une donnée récoltée doit être décrite, avoir une finalité précise, une traçabilité, et des process, notamment les conditions d'accès aux données. Car oui, dans le RGPD, si tu le relis très attentivement, on te demande de documenter des procédures et les flux de données. Oui, je sais, écrire de la doc, c'est toujours bien moins sexy que faire du TDD ou jongler avec ses images dockers… Mais cela t'oblige à réfléchir à 2 fois sur par exemple ton presta de newsletter ou le service d'OCR en PaaS. C'est la raison pour laquelle tu es responsable du choix de ton sous-traitant, et que ce dernier doit t'informer de toute modification dans le process concernant tes données, notamment le recours à sa propre sous-traitance ou la localisation (grossière) de ses serveurs de backups.
(EDIT: j'avais oublié aussi de préciser qu'il y a un process qui est demandé en cas de découverte d'une faille de sécurité. Comme répondre à ces questions : Pourquoi a-t-elle eu lieue ? Comment a-t-elle lieue ? Qu'avez-vous fait pour la limiter dans l'immédiat ? Avez vous les logs d'accès ? Qui a profité de cette faille ? Qui est impacté par les données disséminées ? Que comptez-vous faire pour qu'elle ne se reproduise pas ?. Encore une fois, documenter et que des bonnes pratiques)
Après, il y a de très nombreuses subtilités qui existent déjà dans le droit, mais sont désormais normalisées au niveau Européen ; Comme, par exemple que les coordonnées d'une entreprise uni-personnelle doivent être vues comme celles d'un particulier. Eh oui, ben ça, ça date des premières jurisprudences de la loi de 1978. Et on ne limite pas uniquement aux données commerciales : les salariés sont eux-aussi concernés. D'ailleurs, plutôt que prôner l'effacement, ce qui cause de nombreux autres soucis comme la cohérence de ta base, il vaut mieux recourir à la pseudonymisation, donc utiliser des tables, voire des bases différenciées.
Je suis désolé de ma tartine, mais… La loi c'est comme le code : l'imprécision peut se payer cher
J'ai pris le temps de faire un article orienté pour les DEVELOPPEURS, pour leur donner une idée des implications de cette réglementation. Comment un article de 1300 mots pourrait-ils prétendre résumer l'implémentation de la GDPR qui est composer d'une centaine de pages ? Il s'agit bien évidement de vulgarisation et par conséquent il y a des raccourcis dans l'article. Bien sûr que les données nécessaires aux obligations légales ne peuvent être supprimées (par exemple)…. Je l'explique d'ailleurs dans un des paragraphes plus bas. Je t'invite avec (grand) plaisir à faire un commentaire plus constructif, je l’intégrerai volontiers au sein de l'article.
Oh purée… Lire le RGPD ne suffit pas, il aurait fallut faire aussi relire son article par un juriste.
«Chaque utilisateur ayant un droit à l’oubli, il est nécessaire de prévoir une fonction qui supprime l’ensemble des données personnelles de cet utilisateur.» Alors NON: cela dépend très très fortement de l'intérêt du consommateur, et des autres obligations légales. Écrire ça comme ça décrédibilise totalement le reste de l'article.
Je suis aussi très content de cet outil que j'ai découvert il y a quelques mois ! Je l'ai utilisé dans l'équipe RabbitMQ pour tester nos packages sur tout plein d'OS, y compris Windows : Terraform nous permet de déployer une vingtaine de VMs, lancer le test d'un snapshot de RabbitMQ sur chacune, et enfin détruire les VMs. Ça a remplacé Docker qui ne correspondait pas du tout au cas d'utilisation.
ah tiens c'est drôle je fais mes premiers pas sous terraform en ce moment aussi. Pas toujours simple au début.
Trop de taff pro, trop peu de taff perso :/ J'aimerai finir un deuxième article sur Gatling
beaucoup d'aspects commerciaux aussi, ça n'est jamais une bonne publicité (plutôt le contraire d'ailleurs) de perdre un client comme la mairie de Munich ou de Barcelone.
Le problème de Munin <troll>outre le fait que ce soit du Perl</troll> c'est qu'il te spam de notifications en cas de problème, pas moyen d'être notifié uniquement lors du changement d'état, ou au moins d'espacer les notifications dans le temps sans espacer les checks eux-mêmes.
De mon point de vue, c'est surtout une histoire de conduite au changement pour les utilisateurs.
J'attends avec impatience l'article qui explique pourquoi vous avez arrêter le cloud et rapatrié vos applications sur votre propre réseau ^^
Ce n'est pas qu'un problème technique ces histoires de migration, ce sont aussi des histoires politiques… et ça me fait bien plus peur
Une très bonne nouvelle. Reste à voir si ce sera la même histoire que pour Munich…
revenu
J'ai basculé maintenant sous i3
Site HS :(