7,90 € TTC
p. 04 Tizen, l'autre plateforme mobile open source...
p. 14 Le C.H.I.P : le tueur de framboises ?
p. 26 Un affichage sur papier électronique pour votre Arduino
p. 38 Créez un moniteur de température et d'hygrométrie
p. 50 Contrôlez votre appareil photo numérique avec votre Pi
p. 62 Manipuler et traiter automatiquement vos photos sur Raspberry Pi
p. 78 Prenez des clichés automatiquement en cas de détection de mouvement
p. 86 Votre Raspberry Pi en pont Wifi/Ethernet
p. 94 Intégrer l'Arduino dans une réglette lumineuse : attention à l'alimentation !
À moins de vivre dans une grotte et totalement déconnecté du monde, vous avez sans doute du observer des comportements étranges autour de vous : des utilisateurs de smartphones l’œil rivé sur l’écran semblant errer, perdus, avant de subitement changer de direction ou se précipiter quelques dizaines de mètres plus loin, parfois en témoignant de façon vive et bruyante une certaine excitation. Ne vous inquiétez pas, c’est normal, ce syndrome s’appelle Pokemon Go...
Je ne suis pas fan de Pokemon, mais il y a dans ce phénomène, ou cette mode, quelque chose qui m’a attiré : la possibilité d’utiliser ce système pour des projets et des montages amusants. Nous avons là une sorte de système de géocaching virtuel utilisant une masse de données impressionnante, et ce avec un aspect interactif intéressant. Bref, un terreau propice à la bidouille. Seulement voilà, la société éditrice du jeu, Niantic, ne semble pas apprécier du tout qu’on joue avec ses jeux d’une autre manière que celle initialement prévue (même si c’est bien plus drôle que d’attraper des créatures trimbalant un poireau). Ainsi, bien qu’il soit techniquement possible de se construire, par exemple, un détecteur de Pokemon à base de Raspberry Pi, ceci est totalement contraire aux conditions d’utilisation (TOS) et peut vous valoir une suspension de votre compte utilisateur, sinon pire encore. Nous avons donc une communauté de développeurs « rebelles », essayant par tous les moyens de créer une interface de programmation (une API) ou d’utiliser celle, non publique, déjà existante et, en face, un éditeur essayant, par tous les moyens aussi, de restreindre son utilisation, voire de sanctionner ceux qui s’en servent. Personnellement, je vois cela comme un beau gâchis de temps, d’énergie, d’efforts et de ressources... Bien entendu, on peut parfaitement comprendre que l’objectif poursuivi est tout simplement d’empêcher les joueurs de tricher, mais dans ce cas, pourquoi ne pas disposer d’une API interne réservée au jeu et en proposer une autre, publique, fournissant simplement des informations basiques, accessibles après enregistrement ? Après tout, c’est ce que font déjà d’autres sociétés et en particulier Google, Twitter et Facebook pour leurs services...
Je crois que des choses m’échapperont toujours concernant les choix et la politique de certains acteurs du monde super-connecté dans lequel nous vivons. L’ouverture, la standardisation et la proximité avec les développeurs/hackers les plus inventifs sont autant de principes qui ont, pourtant, déjà fait leurs preuves à maintes reprises...
Devant un tel manque d’ouverture, la réaction la plus intelligente est donc de laisser les ténèbres, l’obstination et l’obscurantisme là où ils sont et passer paisiblement son chemin... (en pestant)
Denis Bodor
Né en 2014, Hackable est un bimestriel destiné aux professionnels et particuliers souhaitant découvrir et progresser dans les domaines de l’électronique numérique et de l’embarqué. Il fournit un contenu riche orienté vers une audience désireuse de bénéficier d'une veille technologique différente et résolument pratique. Le contenu du magazine est conçu de manière à permettre une mise en pratique directe des connaissances acquises et apprendre tout en faisant.

2020 aura été une année marquante pour nos vies et nos sociétés. Il aura fallu se réinventer, trouver des solutions à des situations exceptionnelles. Dans les entreprises, l'Éducation ou la Santé, la mobilisation des ressources informatiques aura été maximale. Nos infrastructures auront ployé, tangué, parfois presque craqué, mais au final, cela aura tenu.
Dans cet article, nous réfléchirons aux besoins de sécurité auxquels nos serveurs devront répondre. Il sera d’ailleurs plus question d’architecture que de serveur personnel. Pourquoi cela ? Car nos besoins vont à coup sûr évoluer dans le temps. L’approche la plus pérenne sera donc de mener une réflexion basée sur des services et non sur un serveur unique. Nous allons aussi nous attacher à assurer la résilience de nos services de base. Nos choix d’architecture auront pour objectif de pouvoir mieux détecter, contrer et éventuellement réparer les dommages causés par une attaque informatique. Nous pourrons par exemple restaurer nos services si un attaquant réussissait à prendre le contrôle du serveur. Notre plan de bataille commencera par la définition des grandes lignes de notre infrastructure, puis par la sélection de nos fournisseurs. Nous déploierons ensuite le serveur avec un premier palier de sécurisation système.
Dans la vie de tous les jours, lorsque l'on perd un objet, on se retrouve la plupart du temps seul face à sa mémoire, sans personne pour vous indiquer où vous avez bien pu poser ces #$*!@& de clés ! Sous Linux, il existe des outils bien pratiques qui vous permettront de gagner un temps appréciable...