PHP 5.6 = faire mumuse avec des constantes + fonctions à arguments variables + ** pour exponentielle + un dbg + on saute php 6 pour php 7 (c'pas nouveau) + « Stream wrappers now verify peer certificates and host names by default when using SSL/TLS » + « mcrypt_encrypt(), mcrypt_decrypt(), mcrypt_cbc(), mcrypt_cfb(), mcrypt_ecb(), mcrypt_generic() and mcrypt_ofb() will no longer accept keys or IVs with incorrect sizes, and block cipher modes that require IVs will now fail if an IV isn't provided. » O_O

J'ai rencontré deux problèmes matériels très bizarres avec mon ordinateur portable Clevo P170HM et je veux partager tout ça.

1) En novembre dernier (11/2013), du jour au lendemain, sans action de ma part, le clavier bug : je ne peux plus rien saisir, aucune touche ne fonctionne. Plus gênant, quelque chose simule, de manière continue et automatique, des touches, comme si je pressais lesdites touches : on obtient donc des entrées "aléatoires" en permanence (exemple : « ^[[2~- +[^[[3~666666666666  »).  Conséquences : impossible d'aller dans le BIOS ... quand la touche F12 fonctionne, l'écran ne s'affiche pas longtemps : quelque chose simule l'appui de echap + enter et fait donc quitter le BIOS. Impossible de saisir des login/mdp (passphrase chiffrement disque, session utilisateur, ...). Un clavier externe USB permet la saisie mais les caractères bidons auto-générés demeurent et rendent la saisie toujours invalide. Avec un live USB (Debian live), on ne peut pas aller bien loin : la simulation auto de touche nous coince dans le menu (touche enter ne marche pas). Débrancher les nappes du clavier et du touchpad ne corrige pas le problème, ce qui exclu la possibilité de saletés (résidus de nourriture par exemple) coincées sous les touches et fait que le clavier n'est pas responsable des entrées débiles. Je trouve un cas approchant sur le web :  http://portables4gamers.com/forum/topic/14455-probl%C3%A8me-d%C3%A9marrage-et-clavier/

Prise en charge hors garantie (ce PC était alors le seul que j'avais et il était trop récent (1 an et demi) pour que je veuille réinvestir dans un nouveau !) par le SAV d'Anyware (revendeur Clevo français) : ils n'arrivent pas à identifier l'origine, changement de la carte mère, plus en stock, attente de Clevo ... longue attente ... Presque 2 mois (7 semaines si mes souvenirs sont exacts) plus tard toujours rien mais appel téléphonique surprise : ils n'ont toujours pas reçu la carte mère de rechange mais l'ordinateur s'est réparé tout seul automagiquement : plus de saisies automatiques débiles. Ils n'arrivent pas à expliquer cette résolution : peut-être ai-je fait tomber un liquide sur le clavier ? Non. Peut-être une sorte de mémoire des touches (?) qui aurait fait de la rémanence ? ... Ce problème ne s'est jamais reproduit depuis.


2) Le week-end dernier (fin août 2014), je mets mon ordinateur en veille (suspend to ram, pas hibernation), comme d'habitude. Le lendemain, appuie sur le bouton on/off comme d'hab pour faire repartir la bête : led s'allume, bruit du lecteur DVD, coupure nette. Les ventilateurs arrières ne sont même pas lancés. On remarque déjà que ce n'est pas une sortie du processus de mise en veille mais bien un boot depuis 0 (sinon le lecteur DVD ne se serait pas affolé). Plusieurs essais, sur batterie uniquement, sur secteur uniquement : toujours pareil. Problème carte mère/CPU/alimentation ? On y va pour démonter la bête : enlever lecteur DVD puis disque dur puis carte WiFi puis RAM ne change rien (tentative de booter à chaque fois). On se rend compte vite fait que ce n'est pas un problème de poussière/surchauffe. Virer la pile CMOS et laisser le PC sans alimentation électrique pendant plus d'1h ne fait rien non plus. Je laisse tomber ... À la fin du week-end, je tente un boot (toujours sans la pile CMOS) : boot OK ! O_O. Aucun problème pendant une semaine puis rechute, de la même manière dans la nuit de vendredi à samedi dernier (5/6 septembre). 24h plus tard sans pile CMOS : boot OK. O_O ÉDIT du 19/02/2015 à 15h15 : ce problème s'est produit à nouveau à plusieurs reprises. La pile CMOS est toujours retirée et il n'était pas nécessaire de débrancher la machine du secteur ni de démonter quoi que ce soit pour que le problème se corrige de lui-même au bout de plusieurs heures. Notons que ce problème n'est plus apparu depuis que j'ai déménagé. Problème de qualité de l'arrivée électrique ? FIN DE L'ÉDIT.


Si quelqu'un peut m'expliquer l'origine de ces pannes totalement cheloues ...

« Twitter perd de l'argent. Beaucoup d'argent. Plusieurs centaines de millions de dollars en 2013 (http://sebsauvage.net/links/?tT3-nQ). Alors il faut rentabiliser. » + une excellente énumération de points qui font que Twitter est un réseau asocial extrêmement fermé et codifié.

Ça ne s'arrêtera pas là. « Vous la sentez venir, la monétisation, là ?  C'est sur votre dos (et votre liberté d'expression) qu'elle va se faire. Vous faites ce que vous voulez, vous êtes prévenu(e). ».

« Mes notes au taff sur samba, avec du LDAP derrière et qui pompe directement dans glusterfs (sans le montage FUSE alakon). Ça juste marche. ».

Glusterfs pour la redondance/sécurité des données + samba pour le partage de fichiers pour des machines winwin + LDAP pour l'auth Samba + ctdb (http://wiki.cbi.netlib.re/mediawiki/Ctdb) pour rendre le service samba hautement disponible (failover, gestion d'IP virtuelles, ...) = MIAM :D

« Chez ARN, FAI associatif alsacien, on a mis en place un serveur DNS récursif-cache ouvert il y a un peu moins d'un an. Il y a quelques précautions à prendre et je n'ai pas trouvé un « how-to » qui ferait le tour de l'essentiel de la problématique. »

Juste pour mon ego :
  - https://twitter.com/bortzmeyer/status/506897671400222720
  - http://seenthis.net/messages/289976

Ho, tiens, du bridage différencié (en fonction du contenu et de la source (itinérance Orange ou non)) sur le réseau Free Mobile. Quelle surprise.

(via http://sebsauvage.net/links/?LTPrxQ)

« Pour Pascal Rogard (PDG de la SACD, un collectif d’ayants-droit), la neutralité du Net, c’est mal.

Pour lui, le problème c’est que : « chaque internaute peut devenir diffuseur et dès lors qu’il devient diffuseur, il porte atteinte naturellement aux droits de propriété intellectuelle ».

Et diffuser ses propres écrits, des fichiers personnels, des photos à soi et des documents en partage libre (licence CC), c’est de l’atteinte à ton copyreich, con@!#* ? »

« Cette fois-ci, c'est presque bon. Après des mois de retards, le Gouvernement a donné le feu vert au Conseil National du Numérique (CNNUm) pour ouvrir sa plateforme de concertation publique sur la future loi sur le numérique, que doit présenter Axelle Lemaire en 2015. Le site est en effet accessible à l'adresse contribuez.cnnumerique.fr. Mais la concertation elle-même n'est toujours pas lancée. »

Où vont-ils chercher des noms de thèmes aussi fourre-tout et bullshit pour des thématiques finalement assez simples puisque fondamentales ? O_O Comme l'explique très bien Numérama, les thématiques proposées sont à double tranchants.

À suivre quand même, au cas où ...

« La liberté d'expression est définie depuis déjà plus de deux siècles, en droit français, par l'article 11 de la Déclaration des Droits de l'Homme et du Citoyen de 1789, ainsi que par la jurisprudence constante du Conseil Constitutionnel dans le domaine. Cependant la protection offerte par ce texte de portée constitutionnelle est, de fait, plutôt théorique. L'article 11, en effet, pose un droit, et ne définit pas un délit.

Ainsi, un citoyen ne peut pas sur le simple fondement de ce texte saisir la justice du fait qu'il soit privé de cette liberté fondamentale.

[...]

L'apparition d'Internet et son développement dans nos sociétés démocratiques a bouleversé les modes d'exercice de la liberté d'expression. Celle-ci ne peut plus continuer à être considérée comme l'exclusivité des journalistes et des acteurs de la presse.

[...]

Les exemples deviennent nombreux de prestataires de service sur Internet qui s'arrogent le droit de censurer, de manière parfaitement discrétionnaire, des propos qu'ils jugent dérangeants, en s'affranchissant de toute décision de justice. [...] Ces exemples, loins d'être exhaustifs, tendent à montrer l'apparition et le développement d'une forme de justice privée de la liberté d'expression sur Internet.

[...]

Le présent texte vise à pénaliser le fait de porter atteinte à cette liberté fondamentale en dehors du contexte, normal, d'une décision judiciaire contradictoire. Il ne vise pas à étendre ou modifier la définition de la liberté d'expression en droit français, mais à rendre cette liberté effective et à la protéger.

[...]

Le texte ne change en rien la définition de la liberté d'expression en France. Dès l'article 11 de la DDHC il est prévu des limitations par la loi, et ces limitations ne sont pas remises en cause. On est donc très loin de l'approche du Premier Amendement de la Constitution des États-Unis qui interdit au législateur d'entraver la liberté d'expression. L'encadrement de la liberté d'expression tel qu'il existe en France (négation de crime contre l'humanité, propos racistes, haineux ou homophobes, etc) n'est pas modifié.

[...]

Les recours au civil portent toujours sur d'autres sujets que la liberté d'expression (droit à l'image, par exemple), sont le plus souvent hasardeux et doivent demontrer un préjudice, le plus souvent financier.

La simple perte de la liberté d'expression, sans autre conséquence pécuniaire directe, ne sera pas traitée, en tant que telle, dans le cadre d'une procédure civile. »

Tiens, je ne connaissais pas les ordinateurs de poche équitables Fairphone.

« Le but du projet Fairphone est de produire un téléphone portable qui soit le plus éthique possible. Par exemple, les smartphones dépendent de beaucoup de minéraux assez rares, comme le tantale ou le tungstène, qui sont souvent produits dans des zones de guerre comme au Congo, la guerre étant souvent entretenue par le désir de s'approprier les mines de ces minéraux. Fairphone tente donc d'obtenir toutes ses matières premières depuis des mines sans conflit. D'autre part, les smartphones sont typiquement construits dans des pays à bas salaire et encore plus basses conditions de travail comme la Chine. Fairphone fait construire ses appareils en Chine, comme tout le monde mais travaille à des meilleures conditions de travail. Bien sûr, rien n'est parfait dans ce domaine et ce téléphone a encore des tas d'imperfections par rapport à son objectif éthique mais l'important est d'aller le plus loin possible dans la bonne direction.

[...]

La batterie est facile à retirer et à changer. Le téléphone est plutôt lourd dans la poche, notamment en raison de son dos métallique.

Du point de vue logiciel, il utilise Android mais est prévu pour pouvoir accueillir plus tard d'autres systèmes. Notez qu'il n'y a pas besoin de le rooter, il arrive déjà rooté (avec l'application SuperUtilisateur, qui demande confirmation avant chaque opération privilégiée). Le Fairphone est donc utilisable par les libristes acharnés.

Pour acheter un Fairphone, il faut aller sur la boutique en ligne (il ne se trouve pas dans les boutiques physiques et évidemment pas sur les gros sites de e-commerce). Il m'a coûté 310 € et une certaine patience : le logiciel de la boutique est assez bogué (les dates de livraison affichées ne sont donc qu'indicatives...), les téléphones arrivent par lots de Chine à des dates pas toujours prévisibles, des cafouillages se produisent... »

« Tout le monde le sait, le système de routage de l'Internet, fondé sur le protocole BGP, n'est pas sûr. Il est trop facile d'y injecter des annonces de routes mensongères. Le premier pas vers une sécurité plus forte était de sécuriser la communication entre routeurs (RFC 5925). Un second pas a été réalisé avec le déploiement de la RPKI. Un troisième pas avec la normalisation de la solution RPKI+ROA. Cette dernière protège uniquement l'origine d'une annonce BGP. Cela suffit à arrêter pas mal d'erreurs mais une attaque délibérée gardera probablement l'origine authentique et trichera sur le chemin d'AS présent dans l'annonce BGP. D'où la nécessité de continuer le travail. C'est le projet PATHSEC (Path Security) pour lequel ce nouveau RFC énumère les motivations. (Le terme de BGPSEC avait été utilisé dans le passé mais PATHSEC semble plus fréquent aujourd'hui.)

[...]

Pour concevoir proprement PATHSEC, il faut analyser les menaces, faire une analyse de risque. Que peut faire un méchant, même si tout le monde a déployé la RPKI et émet des ROA ? [...] Ce RFC détaille les faiblesses, notamment en indiquant celles qui resteront même dans un monde futur où tout les acteurs auront déployé PATHSEC.

[...]

Dans tous les cas, si la session BGP n'est pas protégée, l'attaquant peut faire des choses comme modifier les annonces BGP. Le problème est connu depuis longtemps, le RFC 4272 en parle en détail, et décrit les solutions. En gros, on peut considérer ce problème particulier comme étant résolu depuis des années.

[...]

Autres attaques possibles, moins directes : viser non pas les routeurs mais les machines de gestion du réseau. Si les routeurs sont gérés par un système central, avec Ansible ou Chef ou un logiciel équivalent, prendre le contrôle du système central permet de contrôler tous les routeurs.

[...]

L'attaquant peut viser un dépôt d'objets de la RPKI. S'il détruit les objets du dépôt ou bien rend celui-ci inutilisable, il a réalisé une attaque par déni de service contre la RPKI (voir aussi la section 5, sur ce risque).

[...]

Bien plus grave serait l'attaque réussie contre l'autorité de certification, et plus seulement contre le dépôt de publication. Parce que, cette fois, l'attaquant serait en mesure de créer des objets signés à sa guise. Il n'y a même pas besoin que l'attaquant réussisse à copier la clé privée de l'AC : il suffit qu'il prenne le contrôle du dispositif de gestion des données, avant la signature (c'est pour cela que les HSM ne protègent pas autant qu'on le croit, même s'ils ont le gros avantage de faciliter la réparation, une fois le problème détecté).

L'expérience de DNSSEC permet de prédire que les problèmes provoqués par la négligence, les bogues ou l'incompétence seront sans doute au moins aussi fréquents que les attaques. Pour reprendre une citation dans Pogo, rappelée par notre RFC, « We Have Met the Enemy, and He is Us ».

[...]

Enfin, la section 5 liste les vulnérabilités résiduelles, celles que même un déploiement massif de PATHSEC ne limiterait pas. Par exemple, une AC peut mal se comporter avec ses propres ressources (émettre un ROA pour un de ses préfixes mais avec le mauvais numéro d'AS, suite à une faute de frappe, par exemple). Même avec PATHSEC, quelques risques resteront. On a déjà parlé des fuites (route réannoncée alors qu'elle ne le devrait pas, mais avec un chemin d'AS correct), qu'on peut d'autant moins empêcher qu'il n'existe pas de définition consensuelle de ce qu'est une fuite. Il y a aussi le fait que PATHSEC ne protège pas tous les attributs d'une annonce BGP, alors même que certains sont utilisés pour prendre des décisions de routage. Et puis PATHSEC permet de vérifier une annonce mais pas de vérifier que l'annonce n'a pas été retirée entre temps. Si un lien est coupé, que des routeurs BGP retirent la route, mais qu'un méchant intercepte et détruit ces retraits de route, les anciennes annonces resteront valables un certain temps. »

Et après tout ça, il restera encore à s'assurer que le data plane suit bien le control plane. #IZI \o/

« La sécurité du routage BGP est un sujet de préoccupation sur l'Internet depuis de nombreuses années. Ce protocole ne dispose en effet par défaut d'aucune sécurité, n'importe quel opérateur (ou craqueur ayant piraté les routeurs d'un opérateur) pouvant annoncer une route vers n'importe quel préfixe, détournant, par exemple le trafic d'un service vital. Ce manque de sécurité ne vient pas d'une confiance naïve dans la nature humaine, mais plutôt de la nature même de l'Internet : il n'y a pas (heureusement !) de Haute Autorité Supérieure de l'Internet qui connaitrait tous les opérateurs et pourrait les autoriser et les surveiller. Un opérateur ne connait (et encore, pas toujours très bien) que ses voisins immédiats, et ne sait pas quelle confiance accorder aux autres. Dans ces conditions, la sécurisation de BGP est forcément un projet à long terme. La première grande étape avait été la normalisation et le déploiement de RPKI et ROA. L'étape suivante est la sécurisation du chemin entier (et pas uniquement de l'origine), dont ce nouveau RFC est la cahier des charges. En route donc vers BGPsec ! (Le nom PATHsec ne semble plus utilisé.)

[...]

La cryptographie peut coûter cher en ressources matérielles et un routeur BGP typique a un CPU moins puissant que celui d'une console de jeu de salon. L'exigence 3.6 autorise donc BGPsec à réclamer du matériel nouveau (par exemple des processeurs cryptographiques spécialisés). La compatibilité avec le matériel existant n'est donc pas exigée.

[...]

La cryptographie ne sert pas à grand'chose si on n'a pas de moyen de vérifier l'authenticité des clés utilisés. C'est bien joli de tester l'intégrité d'une signature mais il faut aussi que la clé de signature soit reliée aux ressources qu'on veut protéger (ici, les préfixes d'adresses IP et les numéros d'AS). L'exigence 3.9 dit donc que la solution technique a le droit de s'appuyer sur une infrastructure existante établissant ce lien, comme la RPKI (et qu'évidemment cette infrastructure doit être fiable, cf. section 5). 3.17 ajoute que cette infrastructure doit permettre le choix, par l'opérateur, des entités à qui faire confiance (toutes les mises en œuvre actuelles de la RPKI permettent cela, en éditant la liste des trust anchors).
[...]

L'exigence 3.14 concerne une question de gouvernance. Il a souvent été reproché aux projets de sécurisation de BGP de faire un déplacement de pouvoir, des opérateurs BGP aux RIR qui gèrent les points de départ de la RPKI. Avec le BGP traditionnel, le RIR a un pur rôle de registre, il ne prend aucune décision opérationnelle concernant le routage. Avec un BGP sécurisé, ce n'est plus le cas. Pour rassurer les opérateurs, 3.14 rappelle que, signature correcte ou pas, la décision d'accepter, de refuser, de prioriser ou de déprioriser une annonce doit rester locale au routeur et à son opérateur. La question « que doit faire un routeur BGPsec en recevant une annonce invalide ? » n'a donc pas de sens et les futurs RFC n'y répondront pas. BGPsec permettra de dire « cette annonce est invalide », il ne dira pas quelle politique adopter vis-à-vis de ces annonces.

[...]

La section 4 décrit les exigences spécifiques au traitement des messages BGP UPDATE qui annoncent une nouvelle route ou bien en retirent une ancienne. C'est le moment où il faut valider (exigences 4.1 et 4.2). L'exigence 4.3 dispense BGPsec d'une protection générale contre les attaques par rejeu, qui resteront donc possibles (retransmission d'une annonce BGP qui était valide mais ne l'est plus, vu les changements dans le graphe BGP). Plus difficile, 4.4 demande qu'on puisse se protéger, au moins partiellement, contre le retrait par l'attaquant d'un message BGP.

Pour terminer, la section 5, sur les problèmes généraux de sécurité, rappelle plusieurs choses importantes notamment le fait que la sécurité du routage ne garantit pas celle des paquets IP (« The data plane may not follow the control plane ») et le fait qu'une sécurité de bout en bout, assurée par les deux machines qui communiquent, reste nécessaire. (Il existe d'autres moyens de détourner le trafic que les attaques BGP.)

Le protocole n'est pas encore terminé (ce RFC n'est qu'un cahier des charges) et il n'existe donc pas encore de mise en œuvre de BGPsec dans du code livré aux opérateurs. »

« Un des obstacles à un plus large déploiement de DNSSEC est la nécessité de faire mettre, par le gestionnaire de la zone parente, un enregistrement faisant le lien avec la clé de signature de la zone fille. Cet enregistrement, nommé DS (pour Delegation Signer) est indispensable pour établir la chaîne de confiance qui va de la racine du DNS à la zone qu'on veut sécuriser. Mais, autant signer sa zone ne nécessite que des actions locales, qu'on peut faire tout seul, mettre cet enregistrement DS dans la zone parente nécessite une interaction avec une autre organisation et d'autres personnes, ce qui est souvent compliqué et réalisé d'une manière non standardisée. Ce nouveau RFC propose une méthode complètement automatique, où la zone fille publie les enregistrements de clé localement, et où la zone parente va les chercher (via le DNS) et les recopier. »

Faiblesses du mécanisme :
  - « Comment est-ce que l'agent du parent détecte qu'il y a de nouveaux CDS ou CDNSKEY dans la zone fille ? ». Action manuelle = oubli. Il faudrait que ce mécanisme soit complémentaire à OpenDNSSEC, par exemple mais polling trop coûteux dans certains cas. Pas simple. :/

  - « Si le système d'avitaillement de la zone fille est piraté, le pirate pourra évidemment créer des CDS et CDNSKEY signés. Bien sûr, aujourd'hui, il peut déjà créer des enregistrements mais, dans ce cas, cela permettra peut-être d'étendre la durée de l'attaque (il faudra republier les bons CDS/CDNSKEY et attendre la mise à jour de la parente). »

« Ce matin, Numerama rapportait que l'ancienne ministre Michèle Delaunay a suggéré au gouvernement de mettre en place une signalétique de type CSA sur toutes les pages de tous les sites internet. Nous faisions alors immédiatement remarquer que la proposition était strictement la même, à la virgule près, que celle d'autres élus, formulée quelques mois plus tôt. Une pratique hélas courante chez les députés et sénateurs, qui permet à des lobbys bien organisés de faire parvenir leurs doléances dans les cabinets ministériels, en tenant la plume de parlementaires qui ne prennent pas toujours la peine de vérifier ce qu'ils envoient — le but étant avant tout de faire plaisir à la personne qui fournit le texte à envoyer. »

Hahaha :'). Ça me rappelle http://shaarli.guiguishow.info/?_hdBqQ où la Quadrature était accusée d'être un lobby qui demande aux citoyens d'envoyer des réponses identiques en masse à nos représentants. :') SA-VOU-REUX !

Picomon - ordonnanceur de supervision (comme Nagios, Icinga, Centreon, ...) ultra léger et KISS codé en Python.

Ça fait uniquement du monitoring (avec des alertes mail si désiré) en mode console mais ça le fait bien. Donc pas d'interface web, pas de graphes, pas de reporting, pas de ... fioriture tout simplement.

Ce que j'en retiens :
  - Compatible avec les plugins (programmes de checks) existants ;

  - Threading des mails. Fonctionnalité très pratique pour voir facilement les problèmes qui ne sont pas encore résolus (ils n'ont pas de thread, ça se voit en un clin d'œil dans un MUA) ;

  - On peut assigner un ou plusieurs checks à un ou plusieurs hosts d'un seul coup ;

  - KISS ;

  - Cas d'usage de prédilection : monitoring inter-AS et auto-hébergement. « Il a été conçu dans l'optique d'être léger, par exemple dans le cas de l'auto-hébergement : on peut très bien l'installer rapidement chez un autre auto-hébergé et configurer les vérifications de son serveur @home sans se prendre la tête avec un nagios ou autre zabbix du même tonneau. ». Je confirme que c'est plutôt bien adapté à un Raspberry Pi (ou OlinuXino ou autre ordinateur mono-carte hein) ;

  - Le mail indiquant le retour à la normale d'un service monitoré indique le temps de down toussa ... On n'est plus vraiment loin d'une fonctionnalité de reporting (pour peu que l'admin conserve ses mails). Alors oui, sans graphes et autres trucs clignotants dans une interface web.

« Alors ça c'était le gros truc de vendredi soir, trouver pourquoi SIGUSR1 était bloqué dans picomon. Quand on a eu remarqué que ça ne marchait pas que chez le celui qui est en Debian sid, et que d'autres programmes tel 'dd' ne recevaient pas ce signal, c'est tout de suite allé mieux pour moi. Et puis, en tty ça marchait… il restait à trouver quel programme entre le tty et l'émulateur de terminal masquait le signal. L'explication est toute simple au final… »

GG le debug :O

Petit programme pour voir les fichiers mis en mémoire cache par un système Unix(-like), forcer la mise en cache d'un ou de plusieurs fichiers, ...

« Le DRM protège les intérêts de certaines personnes, dont les ayant droits. Parfois pas très intelligemment et avec un effet positif à démontrer, mais OK.

Le fichier, lui, n’est pas protégé. Il est verrouillé. Et c’est bien différent. »

+1, employons le bon vocabulaire.

(via http://lehollandaisvolant.net/?id=20140831164123)

« L’Allemagne est en quête d’une législation anti-stress. Avec des salariés de plus en plus hyperconnectés, l’enjeu est de lutter contre les risques de burn out pour ceux qui sont continuellement en relation avec leurs emplois, même en dehors des heures de travail.

L’Allemagne envisage une législation pour interdire aux sociétés de contacter leurs employés en dehors des heures de travail. Andrea Nahles, ministre fédérale du travail en Allemagne, a indiqué en ce sens à nos confrères du Rheinische Post qu’une étude était actuellement menée : « il y a une relation indéniable entre la disponibilité constante et l’augmentation des troubles psychiques, comme l’ont également reconnu les employeurs et les études scientifiques. Nous avons commissionnés l’Institut fédéral pour la sécurité et la santé au travail pour voir s’il est possible de définir des seuils de charge. Nous avons besoin de critères universels et juridiquement contraignant avant de prescrire de telles obligations ».

[...]

En France, un avenant à l’accord-cadre de la « branche des Bureaux d’études techniques, cabinets d’ingénieurs-conseils, sociétés de conseil » a programmé « une obligation de déconnexion » pour certains types de contrat. Les cadres travaillant au forfait jour dans ce secteur « bénéficient d'un repos quotidien minimum de 11 heures consécutives et d'un repos hebdomadaire de 35 heures minimum consécutives ». Et leur employeur doit s’assurer dans le même temps « des dispositions nécessaires afin que le salarié ait la possibilité de se déconnecter des outils de communication à distance mis à sa disposition ».

En France encore, la Cour de cassation a déjà jugé en 2004 qu'on ne pouvait justifier le licenciement d'un salarié qui n'avait pu être joint sur son téléphone portable personnel en dehors des horaires de travail. »