Je me suis remis à mes sauvegardes. Le dernier épisode était en septembre et ça commence à faire presque deux ans que rien n’est finalisé.
Je reste sur mon plan précédent. J’ai juste abandonné l’idée d’utiliser Crashplan. Ça part de messages sur des forums où ils disent explicitement qu’ils ne pouvaient pas garantir le bon fonctionnement quand on dépasse quelques To de sauvegarde. Derrière j’ai exploré plus et les débits faméliques rendent de toutes façons illusoire une restauration complète sur des volumes de cet ordre de grandeur en cas de défaillance disque.
J’irai chez BorgBase ou Hetzner, probablement Hetzner parce que même en coupant l’inutile j’ai quand même au moins 3 To aujourd’hui et que va commencer à faire cher chez BorgBase avec l’augmentation naturelle.
Disque externe – Disque interne
Le vrai sujet de ce week-end, c’est comment monter une partition chiffrée depuis un disque externe. C’était déjà mon problème en septembre.
Macos considère que les disques externes sont comme des clés usb, lisibles par tous les utilisateurs, sans droits d’accès, et démontées dès qu’on se déconnecte de sa session.
Passer à un système chiffré empêche qu’il soit montable par tout le monde tant qu’on n’ajoute pas la clé de chiffrement dans le trousseau.
Si c’est monté manuellement, on peut ajouter le paramètre owners pour faire en sorte que le système respecte les permissions sur les fichiers et n’ouvre pas tout à tout le monde.
J’ai pu faire monter le disque au démarrage en ajoutant un plist dans /Library/LaunchDeamons et en le chargeant avec un launchctl load. Le plist exécute un script au démarrage qui déverrouille le disque et le monte avec les bonnes options. Ça veut dire que la clé de chiffrement est en clair dans un fichier du disque interne. Le disque interne est chiffré lui aussi, le fichier n’est lisible que par root. Ce n’est pas parfait mais suffisant pour mon usage.
Ça reste visible comme un disque externe, donc tout le monde peut demander à l’éjecter. J’ai palier au problème ajoutant un petit code dans le script de démarrage qui entre dans le disque et attend indéfiniment. Le disque étant occupé, personne ne peut l’éjecter.
J’ai l’impression de batailler à faire du bricolage sur ce qui m’aurait pris quelques minutes sous Linux mais ça fonctionne.
L’étape suivante ça va être de s’assurer que tous les fichiers se retrouvent sur le disque prévu pour, en synchronisant tous les comptes Google Drive et Tresorit. Ensuite je vais installer un getmail pour archiver en temps réel les boites email, probablement un script pour archiver le Github. La dernière étape sera de brancher Borg pour envoyer le backup en ligne et d’attendre un bon mois qu’il finisse la synchronisation initiale.
Je cherche à ce qu’un script shell reste ouvert comme un démon au lieu de rendre la main après s’être exécuté. Comme un démon, je veux qu’il réagisse en se terminant de lui-même quand il reçoit une demande de SIGTERM.
Ma première approche c’est une boucle infinie avec un sleep.
trap 'quit' SIGTERM SIGKILL
function quit() {
exit 1
}
while true; do
sleep 10
done
Le trap n’interrompt pas le sleep. J’ai mis 10 secondes pour garder une réactivité raisonnable à l’extinction.
Même si un réveil toutes les 10 secondes est probablement insignifiant, quelque chose en moi est quand même gêné et aurait aimé mettre plusieurs heures ici.
Je vois sur le web pas mal d’exemples avec un sleep 1, qui m’interroge encore plus. Quel est le coût réel de ce sleep 10 dans une boucle infinie ?
Certains ont élaboré des solutions pour rendre le sleep interruptible en l’envoyant en tâche de fond :
PID=
trap '[[ $PID ]] && kill "$PID"' SIGTERM SIGKILL
while true; do
sleep 100000 & pid=$!
wait
done
Je vois aussi, et ça m’a l’air simple & smart, des scripts utiliser des readline plutôt que des sleep. Les readline ont la bonne idée d’être interruptibles et de durée infinie tant qu’on n’envoie rien sur stdin.
Dites, les amateurs de shell, quelle est la méthode recommandée pour garder un script ouvert en tâche de fond ? Est-ce qu’il y a une réelle différence entre ces méthodes ou est-ce juste une question de style ?
« Il suffira d’écrire des spécifications complètes et précises »
Je revois cette planche de BD dans une conversation et je trouve qu’elle passe à côté d’un élément fondamental : On ne transmet pas justement pas de spécifications complètes et précises au développeur.
Compléter, préciser
Une grosse partie du boulot de développeur c’est compléter et préciser ces spécifications incomplètes et imprécises.
Compléter, préciser, le tout à partir du contexte projet, des habitudes et de l’implicite courant… C’est le cas d’usage exact des LLM.
On essaie de leur faire faire « de l’IA » mais ces outils sont en premier lieu de formidables outils de complétion à partir d’un contexte et de l’implicite habituel pour un type de tâche donnés. Bref, le travail d’un développeur.
Reformuler dans un langage plus formel
Que fait le développeur d’autre ? Il traduit ça dans un langage formel (le code).
Reformulation, ça aussi c’est le cas d’usage parfait pour les LLM.
La dernière tâche du développeur est très technique. C’est de l’ingénierie logicielle, réussir à tout agencer pour que ce soit facilement testable, maintenable, évolutif, etc.
Une grosse part de cette dernière tâche est basée sur l’apprentissage et la reproduction de motifs ou de pratiques. Le LLM est aussi parfait pour ça.
Il reste aussi qu’il s’agit de rendre les choses testables, maintenables et évolutives… par des humains. Peut être qu’une partie de ce besoin va disparaître ou du moins évoluer le jour où le code sera plus manipulé par des LLM que par des humains. Leurs besoins, facilités et difficultés sont forcément différents des nôtres.
Apprentissage
Oui il faudra faire des aller-retours avec l’outil pour compléter ou corriger sa complétion. Il en va de même du développeur, surtout lors de sa première arrivée dans une équipe ou dans un projet.
Oui un LLM fera des erreurs d’interprétation. Un développeur aussi.
Est-ce que les allers-retours et erreurs seront plus importants que ceux avec un développeur ? Aujourd’hui probablement, demain je n’en sais rien, peut-être.
Est-ce que ces allers-retours et corrections seront plus coûteux qu’un développeur ? Alors là je n’en sais rien, mais je ne parierai pas dessus.
Besoin d’expertise
Est-ce qu’on aura toujours besoin d’un développeur et d’expertise pour accompagner l’outil automatique ? Très probablement sur une partie, oui, mais probablement moins en proportion qu’on n’en a besoin aujourd’hui.
Très certainement aussi que le travail sera différent de celui d’aujourd’hui, et que savoir interagir avec les outils automatiques sera essentiel dans les compétences requises. C’est déjà partiellement le cas aujourd’hui. On ne code pas comme au temps des cartes perforées. C’est juste que les outils vont changer et vont très probablement prendre une plus grande place.
Certitudes
Je ne donne que mes certitudes, mes croyances et mes craintes. Je ne connais pas plus le futur que d’autres. J’ai juste le sentiment, sans aucune technobéatitude, qu’il est en train d’arriver.
On fait faire, dire ou espérer plein de choses quand on parle d’IA. Il ne s’agit pas de voiture volantes et autres IA sentientes ici.
Ici je parle LLM, complétion et reformulation de textes. Je peux me tromper et je ne mets ma main au feu à propos de rien, mais je me base sur des capacités qui sont déjà là aujourd’hui.
Juger le futur
Est-ce souhaitable socialement ? Est-ce soutenable pour la planète ? Comment va-t-on gérer la transition au niveau de la société ?
Ce sont honnêtement d’excellentes questions dont j’aimerais avoir les réponses.
Le fond n’est pas si je souhaite ou pas ce futur, c’est que je constate qu’il est en train d’arriver, et que je veux pas faire semblant de l’ignorer.
Pour les futurs développeurs
Je crains une vraie crise dans le métier dans quelques années. Certains, beaucoup, vont rester sur le carreau.
Je ne sais pas si j’encourage les plus jeunes à se lancer dans le développement informatique. Si vous le faites, je vous encourage à à la fois devenir très vite expert (parce que j’imagine qu’on aura besoin des experts pour compléter les LLM), et apprendre à coder via les LLM (pas juste « avec ») même si ce n’est pas rentable aujourd’hui.
Je suis conscient de la contradiction à demander aux juniors de devenir immédiatement expert.
Je ne suis pas certain qu’il y ait un avenir pour les développeurs moyens, ou pour les junior. Leur valeur ajoutée sera faible et il y aura dans un premier temps suffisamment de développeurs formés pour jouer les experts sans devoir investir des années dans des compétences intermédiaires qui pourraient devenir experts un jour.
Pour choisir son futur
Si vous êtes très tech, faites des maths, de la manipulation de données, des statistiques, et globalement de l’IA. Les places seront peut être chères et demanderont des compétences plus avancées que pour être développeur, mais il y aura du travail.
Si vous avez envie de créer, pour moi l’avenir est plus dans les métiers du produit, des product manager avec une coloration et un intérêt technique. Ça veut dire savoir parler business, marché, client, etc.
Pour les développeurs actuels
Pour ceux qui sont encore majoritairement les mains dans le code, je vous conseille de passer au plus tôt dans le développement via les LLM.
Je sais que vous n’en ressentez pas le besoin, que ces outils font des erreurs que vous ne faites pas, que ça ne vous accélère pas aujourd’hui.
Le fond c’est que les plus jeunes ça les accélère, que demain ils auront développé leur expertise mais sauront aussi utiliser ces outils, et qu’ils en comprendront assez les limites et les défauts pour être l’expert dont le métier aura besoin.
Il y aura encore longtemps de la place pour des vieux experts du code pour la maintenance et pour les gros groupes qui ont plusieurs générations de retard. Il y a aujourd’hui toujours besoin de développeurs et Cobol. La vraie question : Est-ce le positionnement auquel vous aspirez ?
Et moi, directeur technique ?
Honnêtement je ne sais pas. Je ne sais pas bien quel sera mon avenir.
Le management de grandes équipes de développement risque d’être aussi has been demain que les vieux DSI dépassés d’aujourd’hui. Est-ce que je veux être de ceux là ? Je ne sais pas.
J’adorerais prendre la tête d’équipes de data science, mais j’imagine qu’il y a une batterie de docteurs sur les rangs, avec une expertise qui me ferait défaut.
Entre temps je vais probablement au moins essayer d’intégrer des équipes qui ont sont alignées avec tout ce que je viens d’écrire.
Je vois passer pas mal d’affolement et de FUD à propos du nouveau service SafetyCore sur Android.
C’est quoi ?
Le service a été annoncé par Google. Il sert à classer les messages entrants pour identifier les usages malveillants ou douteux. Il identifie aussi la nudité sur les images pour la masquer en l’attente de confirmation de l’utilisateur.
Ce dernier usage est indiqué comme activé par défaut pour les mineurs, qui bénéficieraient aussi d’une alerte informative quand ce sont eux qui envoient des images sensibles.
Tout ça est traité en local. En conséquence, ce n’est pas un service d’espionnage, de tracking ou d’information vers les autorités. Rien n’est échangé avec les serveurs de Google ou envoyé vers une autre destination.
Est-ce qu’on peut avoir confiance ?
La confiance ça ne se dicte pas, et c’est très personnel. Les développeurs de GrapheneOS, qu’on peut difficilement qualifier de pro-Google, ne semblent rien avoir à y redire.
Alors oui, on peut imaginer que maintenant ou à l’avenir, Google utilise ce service ou une future mise à jour de ce service pour un usage malveillant. C’est toutefois vrai avec tous les services de Google, que Google Play met à jour en permanence.
Si vous n’avez pas confiance en Google, le problème n’est pas ce nouveau service. C’est tout l’OS qu’il faut changer, pour un dont Google ne gère pas les mises à jour automatiques. Note : Vous devrez quand même faire confiance à quelqu’un, ce sera juste quelqu’un d’autre.
Ok, mais l’installation est cachée quand même…
Je ne crois pas qu’on puisse dire que l’installation est cachée si l’évolution a été annoncée publiquement il y a plusieurs mois.
Elle par contre automatique. Oui, c’est discutable. Maintenant il faut voir d’où on vient pour comprendre.
Par le passé Android était un nid à problèmes de sécurité. Les constructeurs ne mettaient pas tous les appareils à jour, ou peu longtemps et avec une forte latence.
Google a fait le choix, probablement à raison, de séparer l’OS en deux couches et de s’occuper lui-même de la mise à jour des services cœurs pour répondre à ces difficultés. Il le fait pour les corrections comme pour les évolutions. Si un service cœur change ou s’ajoute, votre téléphone en profite même si le constructeur n’est pas diligent.
Le service dont on parle est bien un service cœur, qui a un rôle de protection. Il est normal qu’il ait suivi la voie de la mise à jour automatique.
C’est discutable mais mieux que l’alternative.
Pourquoi n’est-il pas Open Source ?
Je ne sais pas, mais je peux tenter de supposer.
Le premier point, c’est que c’est un modèle de tri, pas un algorithme. Le code source a moins de sens si le cœur reste un gros paquet binaire.
Ils auraient pu ouvrir le modèle lui-même, avec son apprentissage. Je ne sais pas pourquoi ils ne l’ont pas fait. Peut-être est-ce pour ne pas donner d’indication sur comment éviter le classement, peut-être est-ce juste parce que l’IA est le sujet à la mode sur lequel ils veulent garder un avantage.
Peu surprenant mais c’est bien d’avoir un peu de chiffres.
Tout le monde se met à vouloir injecter de l’IA par principe et s’en vanter, y compris là où ça induit plutôt une perte de valeur pour l’utilisateur (typiquement pour de l’interaction avec les équipes support).
Si je suis étonné, c’est plutôt que l’effet ne soit pas beaucoup plus négatif.
Ceci est un brouillon qui mérite un peu de réflexion mais pour lequel je suis preneur dès à présent de savoir ce que ça vous inspire, ou comment vous vous différenciez par rapport à cette vision.
En pleine introspection, je regarde les décalages par rapport aux attentes qui m’ont été exposées par le passé.
Une de celle là c’est celle du rôle du chef dans les choix et décisions.
Je suis là pour permettre de penser et agir collectivement, pas pour diriger des singes savants.
Crédo personnel
Corolaire : C’est aux sachants proches du terrain de faire les choix et prendre les décisions, pas au management.
Mon rôle c’est de les mettre en capacité, de m’assurer qu’on mette les bons enjeux, les bons moyens, les bons process pour arriver à ce qu’on ait les bonnes personnes pour prendre les bonnes décisions au bon moment sur les bons sujets.
Parfois, souvent, ça veut dire donner une direction, mais dans l’idéal même cette direction peut venir des équipes.
Dans la réalité je prends plein de décisions, tout le temps, avec plaisir et sans tergiverser, mais elles sont sur mes sujets, pas ceux de mes équipes, ou le moins possible.
Je me rappelle l’interrogation d’une équipe il y a plusieurs années à propos d’une mise à jour mineure de PostgreSQL. Fallait-il la faire ?
C’était les premiers mois de la prise de poste. L’équipe n’avait pas eu de directeur avant et ne savait pas trop quoi en attendre.
J’ai posé les questions, savoir s’il y avait un enjeu de sécurité, si ça corrigeait un de nos problèmes, s’il y avait un effort ou un risque particulier à la montée en version. L’équipe avait les réponses, il n’y avait ni enjeu ni risque, j’ai dû répondre quelque chose proche de « comme vous voulez ».
Cette anecdote a mis en évidence plus d’un an après le décalage entre ma conception du rôle et celle de mon président de l’époque. Il aurait voulu quelqu’un qui « donne le ton à l’équipe », dès le début.
Ce décalage est revenue plusieurs fois dans mon histoire, en partie parce mon curseur entre la mise en capacité et la prise de décisions est particulièrement à gauche, mais pas que pour ça.
Il y a dans l’univers professionnel une culture du chef qui reste assez marquée et à laquelle je n’adhère pas. En zone de stress j’ai vu la plupart des directions repartir à la recherche d’un leader éclairé qui alignerait tout le monde en prenant les bonnes décisions inspirantes que les autres n’auraient qu’à suivre.
Je n’y crois pas, pas plus en entreprise qu’en politique. Au mieux ça donne des effets concrets et rapide mais on se prendra très fort le mur quand le chef prendra une mauvaise décision ou s’en ira. Et ça arrivera.
Même avec 25 ans de bagages, je n’ai jamais la prétention de dire « ta gueule je sais ». Je peux me tromper. Je me trompe encore. Si je décide et que j’attends des équipes qu’ils prennent du recul sur les enjeux pour m’arrêter quand je me trompe, ne suis-je pas en train d’inverser les rôles ?
Mon objectif à moi c’est l’opposé, c’est me rendre dispensable, faire en sorte que tout puisse tourner sans moi, y compris les décisions stratégiques et les sujets sensibles.
Si je fais bien mon travail, je peux arrêter de travailler sans que ça ne se voit. Mon but est finalement de ne servir à rien.
Conséquence de mon positionnement
En aparté : Les deux positions en exergues ont — j’espère — l’air saines mais c’est loin d’être une évidence pour tous ni facile à porter. Elles ne facilitent entre autres pas la valorisation de mes propres actions auprès de mes propres encadrants quand eux croient encore consciemment ou inconsciemment au grand leader charismatique qui dirige tout.
J’ai pu individualiser trois phases dans ces cas là :
Une première zone mitigée, parce que la mise en place d’une responsabilité aux équipes ne se fait pas en un jour, et que ça passe par des échecs et une zone de flou quant à qui dirige.
Une zone de confiance ensuite, parce que la machine commence à tourner et que les résultats sont là.
Une zone de défiance voire de rupture de confiance quand il y a une période de stress ou de craintes pour de forts enjeux. Le fait de ne pas voir l’action directe du grand leader fait poser des questions.
Au-delà d’éventuels difficultés concrètes — j’en ai, comme tout le monde — j’ai encore beaucoup de travail sur la communication autour de mon approche : savoir comment montrer, expliciter et rassurer.
Je ne saute pas pour autant à la conclusion que tout doit passer au télétravail et que c’est la seule organisation valable ou saine.
Une fois que l’organisation est assez bonne pour permettre le télétravail, le reste est une question de choix et de culture. Tout est légitime.
Je ne vois pas plus de raison d’imposer le presentiel à ceux qui pourraient télétravailler que d’imposer les conditions du télétravail à ceux qui auraient besoin ou envie de face à face avec leurs collègues.
Vouloir une entreprise purement présentielle est aussi légitime qu’une entreprise qui permet le télétravail.
Allez juste dans l’organisation qui vous correspond. Le télétravail n’est pas l’idéal pour tous.
Personnellement j’aime bien avoir le choix en open bar. Si je peux et que les bureaux ne sont pas loin, je viendrai avec plaisir 2 à 3 jours la plupart des semaines (mais pas forcément toutes), et je préfère avoir un environnement où on se voit quand même tous au moins deux à trois jours par mois.
Ça peut être moins, ou bien moins, mais j’ai du mal aujourd’hui à m’imaginer ne voir les collègues en face à face qu’une fois l’an. Je ne l’ai jamais fait, peut être que c’est une crainte infondée et que ça me demandera juste d’organiser ma vie autrement.
Je crois par contre que j’aurais du mal à m’imposer la venue au bureau tous les jours toutes les semaines, ou même 4 jours par semaine toutes les semaines : J’ai besoin de me retrouver aussi moi-même certains jours pour mon équilibre. L’idéal étant qu’on me fasse assez confiance pour choisir lesquels en fonction du moment.
Pas partout. Ça demande une organisation qui va avec. On parle d’écrit, de communication, d’implication, de prise de responsabilités et de confiance, entre autres.
Ce que ça demande me paraît toutefois pertinent même pour qui souhaite rester en présentiel. Peut être que si pour vous le télétravail ne fonctionne pas, c’est un bon révélateur de ce qui ne fonctionne déjà pas, télétravail ou pas, mais qui est d’aujourd’hui contourné d’une façon ou d’une autre.
Le télétravail démultiplie le problème, il ne le crée pas.
Corrigez vos problèmes. Vous aurez tout le loisir de quand même garder une culture présentielle si vous le souhaitez, mais elle sera d’autant plus fonctionnelle.
Implicitement : prévoir de rester en présentiel le temps de corriger les problèmes de culture et d’organisation (parce que le télétravail les démultiplierait) me semble tout à fait légitime tant qu’effectivement on prévoit un plan pour les corriger.
C’est aussi quelque chose à entendre pour les salariés qui ne voient que l’absence de perte de productivité dans leur propre travail individuel. Parfois, souvent, les problèmes induits sont au niveau de la collaboration, de la coordination, du soutien humain, de l’alignement global, de l’émergence d’idées nouvelles ou de transversalité.
Les managers et directeurs, de par leur rôle, sont plus amenés à percevoir et prendre en compte ces aspects. Écoutez-les aussi au lieu de juste penser qu’ils ne font pas confiance.
Est-ce qu’il y a des bonnes pratiques d’organisation du télétravail qui ne seraient pas aussi des bonnes pratiques en présentiel ? Possible, mais je n’en ai pas en tête.
Dans mon expérience en deux ans dans une entreprise sans bureaux, on avait l’ambition de se voir toutes les 6 semaines dans un co-working à Paris.
On organisait des ateliers mais je suis assez convaincu que se voir était plus important que les ateliers eux-mêmes.
L’ambition était de 6 semaines. Parfois on a fait légèrement moins, souvent on a fait plus. J’ai constaté une détérioration visible de la communication et de la bonne collaboration dès qu’on dépassait 4 à 6 semaines. C’était comme un pivot, pas quelque chose de graduel.
Je ne sais pas si la dégradation que j’ai vu après 4 à 6 semaines nous était propre ou si elle est plus universelle.
Le résultat c’est que dans une entreprise suivante on a demandé aux télétravailleurs de revenir au moins une période de deux jours par mois, idéalement consécutifs.
Je l’ai vu ailleurs mais je n’exclus pas que ce soient juste les têtes gouvernantes qui ont parlé entre eux et repris l’idée. La tech française c’est énormément de cargo cult où on copie ce qui se fait ailleurs.
Ce « deux à trois jours par mois » me semble toutefois un bon compromis là où c’est possible. Ça fonctionnait pour nous.
La communication passait moins bien avec ceux qui ne jouait pas le jeu (sans qu’il me soit clairement possible de dire quel était la cause et quel était l’effet entre leur faible venue et la difficulté de collaboration).
Bref, si je peux choisir et que les distances le permettent, je garderais bien ce « deux à trois jours par mois en commun », sous une forme ou une autre (certaines entreprises donnent juste des budgets aux équipes pour se voir, sous la forme qu’elles préfèrent).
Si se rencontrer souvent ce n’est pas envisageable, l’éventuel coût induit que je décris ne me semble pas insurmontable non plus.
Chaque organisation a ses propres facilités et difficultés. Le présentiel aussi, qu’on voit moins tellement on y est habitué. Il s’agit juste de trouver la bonne organisation qui compense avec d’autres bénéfices.
Dire le contraire serait juste insultant pour les travailleurs de plein d’entreprises de toutes tailles, y compris parmi les plus en vues, qui considèrent que c’est une bonne organisation pour eux. Je l’ai vu moi-même pendant deux ans avec une boîte sans bureaux.
Si vous pensez que ça ne fonctionne pas, le problème est à coup sûr chez vous.
De manière intéressante, les très grands groupes tech qui sont récemment train de revenir vers du présentiel sont habitués à donner des indicateurs chiffrés pour tout et n’importe quoi. Ici, rien pour expliquer les revirements.
Ça ressemble beaucoup à des choix idéologiques de la part des personnes en direction.
