Je procrastine la migration hors Google depuis des années. Je le souhaitais par principe plus que par besoin, et ça ne me motivais pas beaucoup de me retrouver avec moins bien.
La situation géopolitique fait que j’aimerais me retrouver en Europe occidentale ou apparenté. Plus qu’avant. Allemagne, Suède ou Suisse ont potentiellement ma préférence.
J’ai deux options :
Un système tout intégré, email, calendrier, contacts, documents, stockage, tout en ligne avec un (vraiment très) gros quota.
Juste email et calendrier, idéalement carnet de contacts, quota significatif. Je garde le stockage par ailleurs, sur Tresorit ou rapatrié chez moi.
Je cherche des recommandations pour savoir où aller.
Je ne veux pas de solution Outlook/Exchange et j’aimerais éviter l’hébergement de la solution sur AWS, GCP ou Azure même si c’est sur des centre de données Européens.
Email
Je veux pouvoir relier ma boite à plusieurs domaines, avec des adresses catch-all, des limites assez hautes pour les fichiers joints, et un quota assez important (50 Go serait idéal, 5 Go un minimum).
Ce serait vraiment excellent d’avoir un système aussi bon que gmail pour la recherche, la gestion des tags, et surtout des règles de filtrage serveur. Peut-être que je rêve un peu. Point bonus s’il y a un système qui me permet de faire à distance une sauvegarde incrémentale quotidienne de ma boite email.
Je ne cherche pas forcément de chiffrement de bout en bout. S’il y a, je veux qu’il existe un pont local pour interagir en IMAP (Proton le propose, Tuta ne le propose pas à ma connaissance).
Note : Je ne veut pas de chaton ou de copain ou de petit hébergeur pour mes emails, à la fois pour des questions de délivrabilité et pour des questions de confiance/sécurité.
Calendrier
Je veux pouvoir partager mon calendrier avec des protocoles standards (webcal ou caldav), et avoir plusieurs calendriers.
Le chiffrement de bout en bout peut être sympa mais je vois mal comment ça peut fonctionner avec le partage dans les protocoles standards.
Contacts
Rien d’extraordinaire, sinon la possibilité d’interagir avec un protocole standard.
Stockage
Pour en faire mon stockage principal il me faut un énorme quota (on parle en To), un chiffrement de bout en bout (indispensable), la possibilité de partager des fichiers et répertoires au moins en lecture (idéalement en écriture), et des logiciels de synchronisation efficaces à la fois sous Mac et sous Linux. L’interface Linux doit pouvoir être utilisée sans interface graphique.
La contrainte est forte. Je peux accepter une solution qui ne gère pas le stockage, et le gérer par ailleurs de mon côté.
Pour l’instant dans les recommandations je trouve :
Proton, chiffré, avec potentiellement les défauts liés ;
Infomaniak, sans le drive qui n’est pas chiffré côté client ;
OVH pour email et calendrier ;
Migadu, pour email et calendrier ;
Fastmail pour email et calendrier, mais Australien.
Régulièrement, je tourne en rond et je reviens à mon point de départ. C’est le cas aujourd’hui sur le secret de Shamir.
J’ai hésité entre l’ancêtre ssss et le plus récent libgfshare. En poussant un peu j’ai identifié d’autres implémentations qui se veulent plus fiables, par exemple en implémentant une vérification d’intégrité. Plus j’avançais et plus je trouvais d’alternatives et de dérivés. Le dernier étant SLIP-0039.
Je ne vous colle pas tout mais il y a au moins:
ssss, le dinosaure, dont l’URL originale n’est même plus en ligne mais qui est encore dans Debian et qui le restera probablement à vie. Il y a un portage Javascript, et même une version qui permet d’ajouter de nouvelles clés à un partage existant.
libgfshare, qui par rapport à ssss permet de partager un secret d’une taille infinie, et qui lui aussi est dans Debian probablement à vie. Des portages JS existent mais je n’en ai pas trouvé qui permettent d’ajouter de nouvelles clés.
sss, qui se veut plus sécurisé et qui ajoute une garantie d’intégrité du secret. Le README a la bonne idée de faire une liste d’alternatives. Malheureusement je n’ai pas vu de portage JS et je n’ai pas forcément envie de le faire moi sur un objet mathématique que je ne comprends pas. Il ne semble de toutes façons pas particulièrement connu hors de github.
sssa, qui semble avoir plusieurs implémentations, mais à priori ni récentes ni très utilisées.
SLIP39, qui va beaucoup plus loin, avec des notions de groupes sur deux niveaux, une vérification d’intégrité. Il y a l’avantage d’un standard établi (à priori pour des questions de blockchain. Il y a même un portage JS, mais j’ai eu peur de complexifier inutilement la procédure de récupération manuelle.
Bref, j’ai fini par exactement la même conclusion que l’autre fois : Je préfère quelque chose de simple, éprouvé, et le fait de pouvoir ajouter des nouvelles clés après coup a un énorme avantage.
J’ai donc amélioré une vieille implémentation de ssss, et je vais partir de là.
Cet article met probablement le doigt sur une des incompréhensions j’ai avec les interlocuteurs critiques à propos d’ia dans les processus de dev.
Il ne s’agit pas de tout accepter. Oui, l’IA aujourd’hui amène son lot de défauts. Je ne compare pas la qualité de la production de l’IA avec la qualité de la production d’un dev humain.
C’est tout le processus qui change. Ce que je compare c’est le résultat d’un processus historique avec celui où l’IA est au centre. Dans ce second processus on a aujourd’hui un dev qui vérifie, qui relance, qui contraint. C’est un changement de métier.
L’article parle de revue mais les deux points à retenir pour moi c’est que l’humain doit rester en maîtrise et toujours prouver que le résultat est le bon, sans juste faire confiance, et que le volume de code est un ennemi encore plus fort qu’avant parce que l’IA est forte à générer beaucoup de code.
Un des points qui me freine c’est comment maintenir à jour les données. Les mots de passe changent, les instructions aussi.
Par le passé j’avais en tête de simplement donner les clés du gestionnaire de mots de passe et de laisser une note dedans.
Ça faisait le job mais depuis j’ai changé de serveur pour le gestionnaire de mots de passe pour passer à un européen. Un peu plus tard le gestionnaire de mots de passe a imposé une authentification double facteurs par email. Mon authentification email a aussi changé et elle doit être directement dans le secret. Cette authentification email a un double facteur téléphone, et mon verrouillage téléphone va aussi changer régulièrement pour contraintes professionnelles.
Bref, je vais avoir besoin de faire des mises à jour, renvoyer de nouveaux documents à tous les destinataires.
Pourquoi pas, mais plus j’en demande plus je cours le risque que ces documents soient mal stockés, perdus, ou que les versions récupérées par les différents destinataires ne soient pas les mêmes.
Pour l’instant ma solution c’est d’avoir une indirection.
Le secret de Shamir se contente de chiffrer une clé symétrique type AES-256. Le reste est chiffré à partir de cette clé. J’ajoute quelque part la date de génération.
À chaque mise à jour, je peux réutiliser la même clé AES-256, et juste mettre à jour la donnée chiffrée elle-même, accompagnée d’une nouvelle date.
L’avantage c’est qu’il suffit aux destinataires de récupérer chacun un des documents que je leur ai transmis. Ensemble ils pourront toujours retrouver la clé, et la clé permettra de déchiffrer le contenu le plus récent qu’ils auront entre eux, même si tout le monde n’a pas le même.
J’ai une vision assez noire du monde, assez pessimiste du futur, mais je ne comprends pas l’idéalisation du passé.
Non, ça n’était pas mieux avant, peu importe le avant qu’on choisit.
Ce n’était mieux ni sur les conditions de vie, ni sur les libertés, ni sur la santé, ni sur le travail, ni sur la pauvreté, ni sur les dominations, ni sur la justice, ni sur l’espérance de vie, ni sur les violences ou la criminalité, ni sur le confort, ni sur l’alimentation, ni… sur rien en fait.
La télévision et la littérature nous abreuvent d’images qui sont celles d’une minorité de dominants de chaque époque, oubliant que la masse n’avait pas ces conditions de vie et que même cette minorité n’avait pas plein de choses qui sont une évidence pour nous.
Soyons critiques sur le présent, précautionneux sur l’avenir, mais n’idéalisons pas le passé.
Si les enfants font du vélo pour aller à l’école l’hiver en Scandinavie, c’est que le problème est dans nos têtes.
C’est difficile à croire tant qu’on n’a pas passé le cap mais la difficulté principale quand il fait froid, c’est la volonté de sortir. Une fois le choix fait, le froid ne pose pas vraiment de problème.
La réalité c’est que, en France, l’hiver (froid) est probablement plus agréable pour du vélo que l’été (chaleur) ou l’automne (pluie).
Sous les 10 à 15°C
Les températures varient suivant vos sensibilités. Moi je suis assez frileux.
Sous les 10° je m’habille normalement, blouson inclus. J’ajoute juste un sous-casque fin contre le vent. Si vous avez un casque urbain sans ouverture peut-être que le sous-casque est même inutile, d’autant plus si vous avez une visière qui bloque le courant d’air froid.
Le vrai problème ce sont les mains, et l’astuce c’est d’ajouter des manchons au vélo plutôt que de mettre des gants. S’en passer serait une erreur.
Sous les 0 à 5°C
Là ça caille si on ne s’habille pas.
Pour les mains j’ajoute de fins sous-gants de soie (existe aussi en laine mérinos). L’idée du sous-gant est que ça reste fin sans handicaper la dextérité. Ça suffit pour sortir les mains des manchons quelques instants pour indiquer une direction, ou le temps que les manchons se réchauffent.
Pour la tête j’ajoute un vrai bonnet fin (en plus du sous-casque éventuel qui bloque le courant d’air qui sinon passerait à travers le bonnet). L’idée c’est d’avoir un bonnet qui épouse bien la tête pour passer sous le casque, donc sans espace vide au-dessus du crâne et sans revers sur le bas du bonnet.
J’ajoute enfin un legging mérinos fait pour la rando sous le jean qui n’est pas fait pour ça, et des chaussettes merinos trouvées à Carrefour en lieu et place du coton. Ces dernières ne semblent plus être en vente et c’est dommage parce que ça faisait très chaussettes de ville, mais sinon il y a plein de modèles plus sport à Decathlon.
Normalement ça suffit mais comme je suis un frileux et que je mets le même pull qu’en intersaison, je troque aussi le t-shirt coton par un t-shirt merinos de rando.
Je suis frileux et ça tient tranquille les –5°C d’aujourd’hui.
J’ai pris de la laine mérinos pour le confort mais on doit pouvoir diviser le prix par deux en prenant de la laine classique ou polaire.
Contre le vent
Dès qu’on approche les 5°C, le vent peut mordre le visage. Là, si besoin et uniquement si besoin, on peut ajouter un masque sur la partie basse du visage, ou mettre une cagoule fine à la place du sous-casque.
J’ai passé la majorité de ma vie à façonner du code, et j’en ai fait mon métier. Je me suis longtemps vu comme artisan logiciel. Pour moi c’était une des spécificités de notre profession. On ne faisait pas deux fois les choses de la même façon. Sinon c’était automatisable, et automatisé. Le développement logiciel c’était ce qui restait, et c’était de l’artisanat.
Je remets en question cette vision depuis quelque temps.
Fin de l’artisan logiciel
L’arrivée de l’IA change ce qui est automatisable, et donc les activités restantes. J’ai deux futurs auxquels je crois.
Le premier, c’est celui de l’ingénieur qui va mettre en place le cadre, les outils, la surveillance, les documentations, la chaîne de production et de livraison. On passe de l’artisanat à l’usine robotisée, comme plusieurs métiers avant nous.
Le second reste quelque part un artisan, mais un artisan produit plus qu’un artisan logiciel. L’enjeu est de remonter partiellement la chaîne, se concentrer sur ce qu’on veut produire, pourquoi, comment, et traduire le besoin. C’est finalement ce qu’on fait déjà : le développeur traduit des besoins en code. Cette traduction sera différente, et moins proche du code.
Ces deux trajectoires ne s’excluent pas. On pourra sans doute naviguer de l’une à l’autre selon les projets, les envies, les moments de carrière. Mais dans les deux cas, le métier change, radicalement, et l’artisan logiciel ne sera probablement plus au cœur de l’activité d’ici fin 2026.
Ça demande de changer de métier, et ça pose plein de questions.
Moyen ou finalité ?
La question qui m’apparaît prégnante pour cette année 2026, c’est de savoir si on fait du logiciel parce qu’on aime faire du logiciel ou parce qu’on aime faire des choses avec du logiciel.
Jusqu’à présent, les deux étaient assez indissociables. Pour faire des choses avec du logiciel, la meilleure façon était de faire du logiciel, avec attention et expertise. Pour faire un bon logiciel, durable, maintenable, évolutif, il fallait travailler la qualité interne, à la main.
Cette dualité permettait de botter en touche avec un « les deux ». Je ne crois pas que ce soit encore vrai, ni que ça le reste longtemps.
Pour l’amour du code
Il y a toujours un peu « des deux » mais je sais que ce qui me motive principalement : ce que je vais pouvoir faire avec le logiciel, pas le logiciel en lui-même.
Je comprends parfaitement ceux qui ont appris à aimer le code, à le peaufiner, à le faire grandir, et dont c’est la motivation principale. Ceux-là voudront peut-être rester dans l’artisanat logiciel.
Il y a toujours des artisans potiers, céramistes et porcelainiers aujourd’hui. Peu, mais il y en a. Ils répondent à des demandes différentes. Certains sont experts pour des demandes hors normes. D’autres, plus nombreux, visent des objectifs non utilitaires : le luxe, le tourisme, les cadeaux, les symboles, l’héritage historique, l’art.
À quoi est-ce que correspondra l’artisanat dans le logiciel ? Je ne sais pas encore. Peut-être à des systèmes critiques où la confiance exige une main humaine. Peut-être à des créations où l’intention artistique prime sur l’efficacité. Peut-être simplement au plaisir de comprendre ce qu’on construit, ligne par ligne. Il y a un métier à trouver, ce ne sera pas tout à fait le même et il sera probablement plus l’exception que la règle.
Je serai probablement toujours un artisan logiciel. Mes premiers codes datent d’il y a presque 40 ans. On ne remet pas facilement au placard un tel héritage. Je pressens toutefois que cet artisanat ne sera plus mon métier.
Comme les photographes qui n’ont jamais lâché l’argentique et la démarche artistique, je continuerai probablement à coder un peu à la main, mais pour le plaisir. Côté développement on a toujours eu un énorme terrain de jeu hors professionnel avec l’open source. Ça restera probablement.
J’ai craqué et j’ai commandé l’écran (Dell U4025QW) il y a deux mois.
Je veux rédiger ce billet depuis les deux premières semaines mais je n’ai pas su comment le tourner. Ça sera donc un peu brouillon.
Je regrette d’avoir tant hésité
Je crois que c’est le ressenti principal.
Le Dell U4025QW
Changer ses habitudes est difficile. J’ai eu des setups sans écrans externes, avec un 24″, avec un 32″, avec deux 24″ en paysage, avec un en paysage et un en portrait. J’ai même pu tester un 34″ ultra-large. À chaque fois je me retrouvais régulièrement sur l’écran du macbook comme écran principal. Les écrans secondaires restaient accessoires. Un vrai confort mais accessoire.
Ici il ne m’a pas fallu une semaine pour avoir envie de fermer le macbook entièrement, et je le garde fermé depuis.
De l’espace horizontal
Je voulais de l’espace horizontal, pouvoir mettre deux ou trois fenêtres côte à côté. Ça devenait d’autant plus pertinent pour la programmation où l’IA prend un second espace complet à côté de l’espace pour le code.
Les fenêtres sont un peu plus étroites que d’ordinaire mais j’en mets bien trois. À vrai dire, surtout côté web, j’ai l’impression d’avoir surtout perdu de l’espace vide. Je n’affiche rien de moins.
C’est aussi parfait pour l’édition photo, qui était mon troisième usage. Lightroom permet d’afficher ma photo entière, en plus des panneaux de droite et de gauche.
Le pari c’était de trouver le plus large possible mais sans que ça ne devienne inutile ou gênant. J’ai l’impression que c’est réussi.
L’écran fait pas loin de 90 centimètres de large, 30% de plus qu’un 32″. Je ne vois déjà pas les deux côtés sans bouger un peu les yeux. Peut-être est-ce le temps de m’habituer, mais j’ai l’impression que plus large serait non seulement inutile mais probablement contre-productif, à me faire tourner la tête de droite à gauche.
De l’espace vertical
J’ai hésité avec des écrans beaucoup moins chers en 32:9ème. Je craignais d’avoir un ratio avec trop peu de hauteur.
J’apprécie d’avoir pas mal de contexte sur une documentation ou sur du code, et de pouvoir travailler une photo en pleine taille. C’est aussi pratique sur les feuilles de calcul.
Ce que je n’avais pas anticipé c’est les visio conférences où je vois le partage d’écran en taille appréciable malgré l’espace pris en haut et en bas.
J’ai un peu moins de 40 centimètres en hauteur, l’équivalent d’un 32″. Là aussi c’est pari réussi, même si j’aurais peut-être pu me contenter de moins.
Des pixels, plein de pixels
J’ai écarté beaucoup de précédent modèles parce qu’ils avaient une densité de pixels assez faible. Je ne vois pas les pixels, mais le ressenti de qualité est flagrant entre un écran classique 96–110 ppi et un écran double densité dans les 215–225 ppi (les apple-fan parleront de retina).
Ici on est à 140 ppi. Les intermédiaires c’est un peu risqué parce que la mise à l’échelle n’est plus un simple facteur 2. C’est un compromis, mais un écran large en 220 ppi ça n’existe pas, et ça demanderait un nombre de pixels que le thunbderbolt 5 de mon macbook ne saurait pas gérer.
J’ai l’impression que c’est réussi. Sur macos, betterdisplay permet de profiter de la mise à l’échelle qualitative. Je dois avouer qu’il m’arrive toutefois exceptionnellement de le passer à la résolution native.
De la courbure
La courbure c’est le côté qui m’a fait peur. J’ai vu un 34″ droit et je sais que c’était pénible. D’un autre côté les écrans gaming avec leur courbure très prononcée me semblaient vraiment exagérées, surtout pour de l’édition photo.
Bref, là j’ai une courbure légère, qui se fait oublier mais qui me semble pertinente.
De la luminosité et du contraste
C’est peut-être le seul point où j’aurais aimé plus. La luminosité est correcte mais je suis souvent proche des 100%. Je vois la différence avec l’écran du macbook et je n’aurais pas craché sur plus.
Là aussi c’est un compromis. Des écrans de cette taille avec plus de luminosité ça ne court par les rues. Il y aura peut-être un 40″ en OLED dans quelques années mais il y aura toujours une raison d’attendre quelques années de plus, et je suis satisfait de ce que j’ai ici.
Utilisation pratique
J’ai le laptop branché en USB-C, pro ou perso suivant le moment de la journée, fermé sur le côté. La charge est intégrée.
Le clavier et le trackpad sont branchés par cable sur les deux ports USB-C de la face avant. J’aurais préféré les garder en bluetooth mais les brancher fait qu’ils passent automatiquement sur le laptop qui est connecté. La webcam est branchée sur le hub en face arrière et passe elle aussi automatiquement sur le laptop que je connecte.
Le vrai logiciel indispensable c’est betterdisplay, pour la mise à l’échelle comme dit plus haut, mais aussi parce que ça permet d’intercepter les commandes de luminosité et de volume du clavier pour les transmettre à l’écran.
Plusieurs postes
J’ai aussi découvert le partage du clavier et du trackpad entre mac et c’est juste le bonheur. Les deux mac s’auto-détectent tout seuls. Je peux accéder au second laptop comme si c’était un écran supplémentaire, et interagir avec. Ça gère même le copier/coller de façon transparente entre les deux. Quand j’ai besoin de faire un peu de pro au milieu d’une session perso, ou le contraire, il suffit que j’ouvre le laptop sur le côté et c’est parti.
Ça plus handsoff (pour transférer la tâche en cours) et airdrop (pour transférer les fichiers), l’écosystème intégré est quand même plus que confortable.
Tout est transparent, et c’est parfait pour moi.
Le Dell a aussi un hub avec KVM intégré pour utiliser deux sources, un seul écran un seul clavier mais je n’ai probablement pas le droit d’installer un outil qui intercepte clavier et trackpad sur mon ordinateur pro. J’ai fait sans et pour l’instant je ne vois pas trop ce que ça m’apporterait de plus.
Ok, mais est-ce que ça vaut le coup ?
Si on oublie le prix, c’est un grand oui. Je ne vois pas de meilleur choix sur le marché pour une utilisation mixte édition-bureautique.
Il reste que c’est aussi un des plus chers du marché. J’ai la chance de l’avoir pris en promotion et sur du professionnel donc avant taxes et tva, mais même ainsi ça reste cher. On a des écrans larges pour beaucoup moins cher que ça, avec un peu de compromis.
Pas pour le jeu ultra-rapide ni pour le HDR de précision
Et parce qu’on m’a interrogé là dessus : L’écran monte en 120 Hz mais le temps de réaction des pixels n’est pas très bon.
Ce n’est pas un bon écran pour faire du jeu ultra-rapide genre shoot-them-up. Pour des jeux plus lents, genre un factorio, je ne vois rien à y redire (et l’espace disponible est vraiment agréable).
De même, si le rendu des couleurs est correct en HDR, il y a peu de zones distinctes pour la luminosité. Ce ne sera pas le meilleur pour des films en HDR ou du HDR de précision.
Bref, bureautique et édition plutôt que jeux et films. On ne peut pas avoir un écran qui fait tout.
L’agile manifesto n’a rien perdu de sa valeur des années après.
Cet item « l’adaptation au changement plutôt que le suivi d’un plan » est toujours celui qui me semble le plus difficile à faire accepter aux tiers.
On apprend et on découvre des choses en permanence. On fait ce qui doit être fait en fonction des contraintes, des connaissances et des objectifs du moment, indépendamment de ce qui a été prévu ou non.
Les plans sont là pour aider à l’organisation. Le suivi du plan ne doit pas devenir un objectif ou un critère de succès en soi.
Conséquence: Venez discuter autant qu’il le faut à propos de ce qui doit être fait, de ce qui est prioritaire ou non, ou de ce qui le sera à l’avenir. Vous êtes aussi bienvenus à revenir en arrière à propos de ce qui était prioritaire ou non dans le passé, pour voir si on a agit au mieux, pour en tirer les leçons et pour agir mieux à l’avenir.
Les discussions sur comment rester sur le plan prévu, sur pourquoi on n’a pas pu le dérouler entièrement, ou pas dans les temps, sont non seulement du temps mal investi mais assez toxiques. C’est se tromper d’objectif.
Au mieux, ça peut être intéressant de discuter de pourquoi le plan était mauvais et comment faire mieux à l’avenir. Le problème c’est le plan, pas ce qui a été fait.
On risque de ne pas livrer ce qu’on a promis !
Ne promettons pas.
Sérieusement. Le plus souvent ce n’est pas nécessaire. On communique une direction, éventuellement un objectif, pas un engagement de livraison.
L’important devrait être dans ce qu’on fait, pas dans ce qu’on promet. Quand c’est nécessaire on communique sur un objectif général, pas sur le détail, et/ou avec une marge suffisante pour prendre en compte les changements qui pourraient intervenir.
Dans tous les cas, si on fait ce qui doit être fait indépendamment du plan, que le plan n’est pas rempli, c’est le plan qui était mauvais, pas l’exécution.
On a besoin de prédictibilité !
Vraiment ?
Parfois oui. Dans ce cas là la visibilité entre dans les besoins pour décider ce qui doit être fait ou non.
Le plus souvent on cherche la prédictibilité parce qu’on n’assume pas le changement et l’inconnu, pour essayer de rendre les gens heureux au lieu d’avoir des discussions honnêtes.
La solution c’est de communiquer sur le passé (la valeur déjà livrée) et sur le présent (les priorités, les capacités) plutôt que sur le futur (ce qui va être fait).
C’est facile à dire tout ça
Et difficile à faire, on est tous d’accord. Lâcher prise demande beaucoup d’effort, surtout quand on est habitué au contrôle.
