Actus

p.06 Mozilla Common Voice : rendre la reconnaissance vocale ouverte et collaborative
p.08 Côté livres...

Développement

p.10 Enfouissement de données dans un document LibreOffice

Système

p.22 Patroni, un cluster PostgreSQL simple et rapide

Dossier : Spécial Devops

p.48 Du sysadmin au dev : Des commandes Shell pour les développeurs
p.62 Du dev au sysadmin : Apprenez à concevoir et distribuer vos applications sur plusieurs plateformes avec CMake
p.78 Du sysadmin au dev : Git, le gestionnaire de versions pour tous les développeurs
p.102 Du dev au sysadmin : Automatisez les tests et évitez les régressions

Repère

p.116 Web crawler / pilote web Selenium : comment automatiser des tâches répétitives d'accès à un site web

Tout est toujours une histoire de compromis en informatique :

• Vais-je privilégier la vitesse d’exécution ou minimiser l’utilisation de la RAM ?
• Utiliser une architecture complexe et fortement maintenable ou développer rapidement un petit script « jetable » ?
• Etc.

Récemment j’ai dû configurer mon nouvel ordinateur portable avec toutes les galères inhérentes à l’installation d’un Linux (et plus encore une Debian) avec des drivers propriétaires pour le moindre composant. J’ai pris l’habitude de chiffrer mon disque dur, ce qui paraît d’autant plus logique sur un matériel nomade que l’on peut plus facilement perdre ou se faire voler. Et c’est là qu’apparaît une nouvelle fois la question du compromis :

• Est-ce que je vais chiffrer la partition /home et utiliser LUKS et LVM ?
• Ou est-ce que je vais me contenter de chiffrer mon répertoire utilisateur ?

Le premier cas sera plus sécurisé, mais il ne sera pas nécessairement le plus pratique : je vais devoir taper deux clés de vingt caractères minimum chacune à chaque démarrage (il faut nécessairement chiffrer également la partition de swap, d’où les deux partitions). Si je ne veux pas les taper, je pourrai les enregistrer sur une clé USB que j’insérerai au démarrage. Question : je suis en déplacement, je suis fatigué, j’ai oublié mes clés kilométriques (il suffit d’une erreur sur un caractère, ce qui est vite arrivé, je parle d’expérience…), et j’ai perdu ma clé USB ; comment est-ce que je fais pour travailler ?

Le deuxième cas sera moins sécurisé, mais simplement avec mon login et mon mot de passe je pourrai déclencher le déchiffrement du répertoire. L’opération sera donc tout à fait transparente pour moi et je n’aurai pas la hantise de me retrouver coincé loin de mes pénates avec un ordinateur parfaitement inutilisable.

La sécurité des données est quelque chose d’important, mais ne doit pas venir alourdir notre vie de tous les jours. J’ai donc choisi la deuxième configuration.

Cette expérience m’a rappelé une discussion que j’avais eue avec une bibliothécaire qui, dans le cadre de son travail, devait se connecter au site polars-addict.com mais qui a dû émettre une demande spéciale de connexion au site, celui-ci étant bloqué (eh oui, il y a le mot « addict » - soit « accro » ou « toxicomane » - dans l’URL !). Deux mois plus tard, elle a pu accéder au site et poursuivre son travail : la magie des whitelists ! Il est vrai que pour le responsable de la sécurité c’est beaucoup plus simple à gérer... par contre pour les utilisateurs du réseau, il est tout de suite beaucoup plus compliqué de travailler !

Je me répète souvent, mais n’oubliez pas que les applications que nous développons ou les outils que nous mettons en place sont la plupart du temps dédiés à des utilisateurs et qu’il faut les adapter à leurs besoins et à leurs compétences ! Nous forgeons leurs outils et, certes, ils auront moins de risques de se blesser avec une petite cuillère qu’avec un corsèque, mais contre un dragon ce sera nettement moins efficace ! Il faut choisir le juste milieu...

Tristan Colombo