Cédrix
1 line
50 KiB
JSON
1 line
50 KiB
JSON
[{"uuid":"cbfbc502-df32-42eb-a99f-3a75cfcc22e0","slug":"creer-un-point-d-acces","title":"Créer un Point d'Accès Wifi (AP)","category":"Électronique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2020-12-06 18:46:23","created_at":"2020-12-06 18:46:23","updated_at":"2020-12-06 18:46:23","tags":[],"plain":"Un point d'accès Wifi (AP) consiste à créer un réseau Wifi avec nom (appelé SSID). Ci-dessous, un code pour créer rapidement un point d'accès Wifi avec l'ESP 8266. Le nom de réseau s’appellera ESP1 - AP, stockée dans la variable ssid."},{"uuid":"104a8694-4268-4e0a-99c7-e7ecfd47af1e","slug":"auto-heberger-son-serveur-mail-en-2026","title":"Auto-héberger son serveur mail en 2026","category":"informatique","author":"cedric@abonnel.fr","cover":"cover.svg","published":true,"published_at":"2026-05-12 08:35","created_at":"2026-05-12 08:38:14","updated_at":"2026-05-12 08:40:06","tags":[],"plain":"Survivre aux règles de Gmail, Outlook et consorts\r\nContexte — Cet article de Clubic (lien) rappelle une vérité technique : SMTP date de 1982, n'a aucune sécurité native, et toutes les \"rustines\" (SPF, DKIM, DMARC, MTA-STS, DANE) ont été conçues par Yahoo, Cisco, Microsoft, Google. Depuis février 2024 (Google) et mai 2025 (Microsoft), tout expéditeur dépassant 5000 mails/jour vers Gmail/Outlook doit configurer SPF + DKIM + DMARC, maintenir un taux de spam < 0,1 %, et fournir un lien de désinscription en un clic.\r\nMais même en dessous de 5000/jour, ces règles s'appliquent en pratique : sans elles, ton mail finit en spam ou est rejeté. Ce dossier décrit comment monter son propre serveur mail tout en passant à travers ces filtres.\r\n--\r\n\r\nSommaire\r\n\r\n1. Avant de commencer : est-ce vraiment une bonne idée ?\r\n2. Prérequis techniques\r\n3. Architecture cible\r\n4. Choix du fournisseur et de l'IP\r\n5. Configuration DNS complète\r\n6. Installation du stack mail\r\n7. SPF, DKIM, DMARC : les rustines obligatoires\r\n8. MTA-STS, TLS-RPT, DANE : aller plus loin\r\n9. PTR (reverse DNS) et HELO\r\n10. Warmup d'IP : la phase la plus délicate\r\n11. Postmaster Tools, SNDS, FBL\r\n12. Liste de désinscription en un clic (RFC 8058)\r\n13. Anti-spam entrant et hygiène\r\n14. Monitoring, logs, alertes\r\n15. Que faire quand Gmail rejette quand même ?\r\n16. Checklist finale avant mise en prod\r\n17. Annexes : commandes utiles\r\n--\r\n\r\n1. Avant de commencer : est-ce vraiment une bonne idée ?\r\n\r\nL'auto-hébergement mail est techniquement possible, mais c'est probablement le service le plus pénible à maintenir en 2026. Avant de te lancer, lis ça :\r\n\r\nCe qui marche bien en auto-hébergé :\r\nRecevoir du mail (presque tout le monde te livre).\r\nEnvoyer vers d'autres serveurs auto-hébergés ou pros bien configurés.\r\nGarder le contrôle sur tes données, tes alias, tes domaines.\r\n\r\nCe qui est dur :\r\nEnvoyer vers Gmail / Outlook / Yahoo / iCloud sans atterrir en spam.\r\nSortir d'une blacklist une fois dedans.\r\nMaintenir un score de réputation IP correct sur la durée.\r\nSurvivre à un changement unilatéral des règles côté gros acteurs (cf. février 2024 et mai 2025).\r\n\r\nStratégie réaliste recommandée :\r\nRéception entrante : auto-hébergée à 100 %. Aucun risque, full contrôle.\r\nEnvoi sortant : deux options, selon ton volume et ton tolérance au risque.\r\nOption A — Pure auto-hébergée : tu envoies directement depuis ton serveur. Faisable, mais demande un warmup, une IP propre, et un suivi continu.\r\nOption B — Smart host sortant : tu envoies via un relais réputé (un autre de tes serveurs avec une IP qui a déjà sa réputation, ou un service type Mailjet/Sendgrid/SMTP2GO en bas volume gratuit). Tes mails sortent depuis l'IP du relais, qui a déjà sa réputation faite. C'est un compromis : tu perds une partie de la souveraineté technique, mais tu gagnes énormément en délivrabilité.\r\n\r\nLe reste du dossier suit l'option A — tout en t'expliquant comment basculer en B si nécessaire.\r\n--\r\n\r\n2. Prérequis techniques\r\nÉlément | Détail |\r\n---|---|\r\nDomaine | À toi, registrar peu importe, mais avec DNSSEC activable (cf. §8 pour DANE). |\r\nServeur | VPS ou dédié, 2 vCPU / 4 Go RAM minimum, Debian 12+ ou Ubuntu 24.04 LTS. |\r\nIP fixe v4 | Indispensable. IP \"résidentielle\" ou IP de datacenter récemment recyclée = exclues. |\r\nIP fixe v6 | Recommandée, mais désactivable si l'IPv6 du fournisseur est blacklistée. |\r\nPTR / reverse DNS | Modifiable par toi. Si l'hébergeur ne te le permet pas, change d'hébergeur. |\r\nPorts | 25, 465, 587, 993, 4190 ouverts sortants ET entrants. Le port 25 sortant est bloqué chez beaucoup d'hébergeurs grand public (OVH résidentiel, Free, etc.) : vérifie avant. |\r\nTLS | Certificat valide (Let's Encrypt suffit). |\r\n\r\nCompétences attendues : Linux en ligne de commande, DNS (champs A/AAAA/MX/TXT/SRV/CAA/TLSA), notion de TLS, lecture de logs et .\r\n--\r\n\r\n3. Architecture cible\r\n\r\nUn stack standard, éprouvé, en logiciels libres :\r\n\r\n\r\n\r\nComposants :\r\nPostfix : MTA. Reçoit, route, envoie le SMTP.\r\nDovecot : serveur IMAP/POP3, livraison locale (LMTP), authentification SASL pour Postfix, gestion Sieve (filtres).\r\nRspamd : antispam moderne, fait aussi la vérification SPF/DKIM/DMARC entrante, le greylisting, et — option recommandée — la signature DKIM sortante (en remplacement d'OpenDKIM).\r\nLet's Encrypt (certbot) : TLS.\r\n(Optionnel) Roundcube ou SnappyMail : webmail.\r\n\r\nAlternative tout-en-un : Mailcow ou Mailu, basés sur Docker, qui empaquètent tout ça avec une interface admin. Si tu préfères ne pas tout configurer à la main, c'est légitime — la majorité des règles DNS et de délivrabilité de ce dossier restent identiques.\r\n--\r\n\r\n4. Choix du fournisseur et de l'IP\r\n\r\nLe choix de l'hébergeur conditionne la moitié de ta délivrabilité. Avant de prendre un VPS :\r\n\r\n1. Le port 25 sortant est-il ouvert ? Beaucoup d'hébergeurs le bloquent par défaut pour limiter le spam (Hetzner l'ouvre sur demande, OVH l'ouvre selon le produit, Scaleway l'ouvre selon le compte). Pose la question au support avant de payer.\r\n2. Le PTR est-il configurable ? Si non, change.\r\n3. L'IP a-t-elle été utilisée par un spammeur ? Avant d'acheter le VPS, demande l'IP qu'on te donnera. Vérifie sur :\r\nmxtoolbox.com/blacklists.aspx\r\nmultirbl.valli.org\r\ntalosintelligence.com (Cisco)\r\nsenderscore.org\r\n \r\n Si l'IP est listée sur Spamhaus, Barracuda, SORBS, SpamCop, demande à l'hébergeur de te l'échanger ou prends un autre VPS. Une fois listée, tu vas y passer des semaines.\r\n4. Réputation du subnet (). Même si ton IP est propre, si le est pourri (beaucoup de spammeurs voisins), Gmail va te traiter avec méfiance. Vérifie sur senderscore.org en saisissant ton IP — le score du subnet apparaît.\r\n\r\nHébergeurs réputés corrects pour le mail : Hetzner, OVH (gamme dédiée, pas SoYouStart), Scaleway, Infomaniak (en VPS), Netcup. À éviter pour de l'envoi : DigitalOcean (subnets souvent grillés), Linode/Akamai (idem), AWS EC2 (le port 25 est limité par défaut, et la rate-limit est costaude).\r\n--\r\n\r\n5. Configuration DNS complète\r\n\r\nPour un domaine avec un serveur mail sur à l'IP (et en v6) :\r\n\r\n\r\n\r\nDétails dans les sections dédiées plus bas.\r\n\r\nÀ ne pas oublier : l'enregistrement PTR (reverse DNS) se configure chez ton hébergeur, pas dans ta zone DNS. Il doit pointer . C'est traité au §9.\r\n--\r\n\r\n6. Installation du stack mail\r\n\r\nSur Debian 12. Ce qui suit est volontairement condensé — pour une configuration ligne par ligne, suis le tutoriel de référence de Workaround.org qui est l'étalon depuis 20 ans.\r\n\r\n\r\n\r\nPostfix : configuration minimale-mais-saine\r\n\r\n\r\n\r\nDovecot, Rspamd\r\n\r\nCes composants demandent leurs propres fichiers de configuration. Renvoi explicite vers les tutos qui font autorité :\r\nWorkaround.org / ISPmail : https://workaround.org/ispmail/ — référence francophone et anglophone, mise à jour à chaque version Debian.\r\nRspamd quickstart : https://www.rspamd.com/doc/tutorials/quickstart.html\r\nDovecot wiki : https://doc.dovecot.org/\r\n\r\nSi tu veux gagner du temps, Mailcow () est aujourd'hui la solution clé-en-main la plus fiable.\r\n--\r\n\r\n7. SPF, DKIM, DMARC : les rustines obligatoires\r\n\r\nSans ces trois enregistrements correctement configurés, Gmail et Outlook rejetteront ou marqueront en spam la majorité de tes messages — peu importe ton volume.\r\n\r\nSPF (Sender Policy Framework)\r\n\r\nDéclare qui a le droit d'envoyer du mail pour ton domaine.\r\n: autorise les serveurs listés dans le MX du domaine.\r\n: rejet strict de tout le reste. Indispensable pour la réputation. Ne jamais utiliser (softfail) en prod : Gmail aujourd'hui considère comme un signal faible.\r\n\r\nSi tu envoies aussi via un relais externe (smart host) : ajoute son , ex. .\r\n\r\nLimite : un enregistrement SPF doit tenir en 10 lookups DNS maximum. Au-delà, il est invalide. Vérifie avec https://www.kitterman.com/spf/validate.html.\r\n\r\nDKIM (DomainKeys Identified Mail)\r\n\r\nSigne chaque mail sortant avec une clé privée. Le destinataire vérifie la signature via la clé publique publiée en DNS.\r\n\r\nGénération de la clé (Rspamd, sélecteur , clé 2048 bits) :\r\n\r\n\r\n\r\nLe fichier contient l'enregistrement DNS à publier :\r\n\r\n\r\n\r\nConfiguration Rspamd () :\r\n\r\n\r\n\r\nRecharge : .\r\n\r\nVérification : envoie un mail à check-auth@verifier.port25.com, tu reçois un rapport complet SPF/DKIM/DMARC en retour. Ou utilise https://www.mail-tester.com/ (note sur 10).\r\n\r\nDMARC (Domain-based Message Authentication, Reporting and Conformance)\r\n\r\nDit aux serveurs distants quoi faire en cas d'échec SPF/DKIM, et te renvoie des rapports sur ce qui passe et ce qui rate.\r\n: surveillance seule, à utiliser pendant 2-4 semaines en démarrage pour collecter les rapports sans pénaliser.\r\n: mise en spam des mails non authentifiés. Cible normale.\r\n: rejet pur. À atteindre en cible finale, après avoir vérifié 4 semaines de rapports propres.\r\n: adresse pour les rapports agrégés (quotidiens).\r\n: rapports forensiques (par message). Optionnel.\r\n: alignement strict — le domaine de signature DKIM et le domaine SPF doivent exactement correspondre au domaine .\r\n\r\nLecture des rapports DMARC : ils arrivent en XML, illisibles. Utilise un parseur :\r\nPostmark DMARC Monitoring (gratuit, agrège les rapports dans une UI).\r\nparsedmarc (auto-hébergeable, envoie dans Elasticsearch/Splunk/Grafana).\r\n--\r\n\r\n8. MTA-STS, TLS-RPT, DANE : aller plus loin\r\n\r\nCes standards sécurisent le transport entre serveurs (chiffrement TLS forcé). Gmail les regarde, Microsoft aussi. Pas obligatoires, mais ils boostent ta réputation.\r\n\r\nMTA-STS\r\n\r\nForce les serveurs distants à utiliser TLS pour t'envoyer des mails. Trois éléments :\r\n\r\n1. Enregistrement DNS TXT :\r\n\r\n\r\n2. Sous-domaine servant un fichier en HTTPS à :\r\n\r\n\r\n est la cible. En démarrage, mets pendant 1-2 semaines.\r\n\r\n3. Certificat TLS valide sur ce sous-domaine (déjà fait via certbot au §6).\r\n\r\nTLS-RPT\r\n\r\nDemande aux serveurs distants de t'envoyer des rapports en cas d'échec TLS.\r\n\r\n\r\n\r\nDANE (DNS-based Authentication of Named Entities)\r\n\r\nEncore plus solide que MTA-STS, mais nécessite DNSSEC activé sur ton domaine. Si ton registrar ne supporte pas DNSSEC, oublie DANE.\r\n\r\nDANE publie un hash du certificat TLS dans un enregistrement TLSA :\r\n\r\n\r\n\r\nOu plus simplement avec https://www.huque.com/bin/gentlsa :\r\n\r\n\r\n\r\nVérification globale de tout ton setup TLS+DANE : https://internet.nl/mail/ (excellent, recommandé).\r\n--\r\n\r\n9. PTR (reverse DNS) et HELO\r\n\r\nLe PTR est probablement la cause la plus fréquente de rejet par Gmail/Outlook chez les nouveaux auto-hébergés.\r\n\r\nRègle absolue : , et tout doit être un FQDN cohérent.\r\n\r\nConfigure le PTR dans le panneau de ton hébergeur (chez OVH : \"IP\" → \"Reverse DNS\") :\r\n\r\n\r\nVérifie :\r\n\r\n\r\nDans Postfix, et c'est ce qui est annoncé en HELO. Cohérence garantie.\r\n--\r\n\r\n10. Warmup d'IP : la phase la plus délicate\r\n\r\nUne IP neuve = pas de réputation = défiance maximale des gros acteurs. Tu ne peux pas envoyer 1000 mails le jour 1 sans te griller.\r\n\r\nPlan de warmup sur 4 à 6 semaines\r\nSemaine | Volume max/jour vers Gmail+Outlook | Volume max/jour total | Contenu |\r\n---|---|---|---|\r\n1 | 20-50 | 100 | Mails à toi-même, comptes test sur Gmail/Outlook/Yahoo. Réponds-y, marque \"non spam\" si en spam. |\r\n2 | 100 | 300 | Cercle proche qui sait répondre / interagir. |\r\n3 | 300 | 1000 | Élargissement progressif. |\r\n4 | 800 | 3000 | Ouvre aux usages normaux. |\r\n5+ | 2000+ | volume cible | Stable. |\r\n\r\nRègles d'or pendant le warmup :\r\nPas de mailing list, pas de notifs automatiques en masse. Privilégie des mails 1-à-1 conversationnels.\r\nDemande aux destinataires de répondre — un mail avec réponse a 100x le poids d'un mail ouvert silencieusement.\r\nAucun lien raccourci, aucun pixel de tracking, aucune image lourde.\r\nStop net si ton score Senderscore baisse ou si Gmail Postmaster Tools (cf. §11) montre du rouge.\r\n\r\nSi tu as un volume immédiat à envoyer\r\n\r\nBascule en option B (smart host) le temps du warmup, puis rapatrie progressivement en interne en répliquant les volumes ci-dessus.\r\n--\r\n\r\n11. Postmaster Tools, SNDS, FBL\r\n\r\nLes gros acteurs te donnent des dashboards dédiés. Inscris-toi à tous, dès la création du domaine.\r\nService | Acteur | Usage |\r\n---|---|---|\r\nGoogle Postmaster Tools | Gmail | Réputation IP+domaine, taux de spam, authentification, encryption. Indispensable. |\r\nMicrosoft SNDS | Outlook/Hotmail | Smart Network Data Services, qualité de l'IP. |\r\nMicrosoft JMRP | Outlook | Junk Mail Reporting Program, FBL Microsoft. |\r\nYahoo CFL | Yahoo | Complaint Feedback Loop. |\r\nValidity Sender Score | Indépendant | Score sur 100, à surveiller. |\r\n\r\nConfigure les feedback loops (FBL) : quand un destinataire clique \"spam\", tu reçois une notification. Ça te permet de désinscrire l'utilisateur avant qu'il ne dégrade ta réputation.\r\n--\r\n\r\n12. Liste de désinscription en un clic (RFC 8058)\r\n\r\nExigence Google/Microsoft pour les expéditeurs en volume, mais à mettre en place dès le début même en bas volume.\r\n\r\nAjoute deux en-têtes à tous les mails non-strictement-personnels :\r\n\r\n\r\n\r\nL'URL HTTPS doit accepter une requête POST (pas seulement GET) avec dans le corps, et désinscrire immédiatement et silencieusement sans demander de confirmation.\r\n--\r\n\r\n13. Anti-spam entrant et hygiène\r\n\r\nUn serveur mail mal configuré côté entrée devient vite un relais de spam ou une cible. Configuration Rspamd minimale :\r\n\r\n\r\n\r\n\r\n\r\nActive aussi :\r\nVérification SPF/DKIM/DMARC entrante (par défaut activée dans Rspamd).\r\nRBL (Realtime Blackhole Lists) : Spamhaus ZEN, Barracuda. Attention à ne pas multiplier — 2 ou 3 RBL fiables suffisent.\r\nGreylisting : refuse temporairement les premiers contacts, ce qui élimine 80% du spam basique. Ne pas activer sur un domaine à fort volume transactionnel (gêne les notifs).\r\nBayes : laisse Rspamd apprendre via le dossier de Dovecot (signal / ).\r\n\r\nMises à jour : activé, redémarrage planifié, lecture des annonces sécu Postfix/Dovecot.\r\n--\r\n\r\n14. Monitoring, logs, alertes\r\n\r\nSans monitoring, tu découvres les problèmes par les utilisateurs. À mettre en place :\r\nLecture des logs : , , web UI de Rspamd sur .\r\nMétriques : exporter Postfix/Dovecot vers Prometheus + Grafana (, ).\r\nAlertes sur :\r\nFile d'attente Postfix > 50 messages ().\r\nScore Senderscore qui chute.\r\nApparition sur une RBL : surveillance automatisée par https://multirbl.valli.org/ ou via un script qui interroge plusieurs DNSBL en cron.\r\nÉchec TLS-RPT (rapport entrant signalant une connexion non chiffrée).\r\nRapports DMARC parsés régulièrement (cf. §7).\r\n--\r\n\r\n15. Que faire quand Gmail rejette quand même ?\r\n\r\nÇa arrive. Diagnostic dans l'ordre :\r\n\r\n1. Lis le code de rejet SMTP dans . Gmail renvoie des codes très explicites :\r\n→ contenu jugé spammy. Revois le contenu, ajoute du texte conversationnel, retire les liens douteux.\r\n→ tu as dépassé un seuil. Ralentis immédiatement, attends 24-48h, reprends doucement.\r\n→ ton DMARC ne passe pas. Revérifie SPF/DKIM/alignement.\r\n→ tu es sur une RBL. Va sur spamhaus.org/lookup/ pour vérifier et demander la sortie.\r\n2. Va dans Postmaster Tools (§11). Si \"IP reputation\" est rouge ou orange, regarde le contenu et le timing de tes envois récents.\r\n3. Test mail-tester : envoie à une adresse fournie par mail-tester.com, obtiens une note sur 10. Vise 10/10. Toute case manquante doit être corrigée.\r\n4. Sortie de blacklist : la plupart des RBL (Spamhaus, Barracuda) ont un formulaire de retrait. Spamhaus retire en quelques heures si tu corriges la cause. SORBS est plus lent. UCEPROTECT exige souvent de payer — ignore-la, peu de serveurs sérieux la consultent.\r\n5. Si rien ne marche, change d'IP. C'est parfois la seule issue. Demande à ton hébergeur une IP fraîche, refais un warmup.\r\n--\r\n\r\n16. Checklist finale avant mise en prod\r\n\r\nAvant d'envoyer le premier vrai mail :\r\n[ ] Domaine avec DNSSEC activé.\r\n[ ] IP testée sur 5+ blacklists, propre.\r\n[ ] Port 25 sortant ouvert et testé ().\r\n[ ] PTR configuré et cohérent avec le HELO.\r\n[ ] MX, A, AAAA, SPF, DKIM, DMARC publiés et validés via mxtoolbox.com.\r\n[ ] MTA-STS publié (mode au démarrage).\r\n[ ] TLS-RPT publié.\r\n[ ] DANE/TLSA publié (si DNSSEC OK).\r\n[ ] CAA publié.\r\n[ ] Test envoyé à : tout en .\r\n[ ] Test mail-tester.com : 10/10.\r\n[ ] Test internet.nl/mail/ : 100%.\r\n[ ] Inscription Postmaster Tools, SNDS, JMRP, Yahoo CFL.\r\n[ ] DMARC au démarrage, parser de rapports en place.\r\n[ ] List-Unsubscribe + List-Unsubscribe-Post implémentés.\r\n[ ] Plan de warmup affiché et respecté.\r\n[ ] Monitoring file d'attente + RBL en place.\r\n[ ] Backup chiffré des Maildir.\r\n\r\nAu bout de 4 semaines de rapports DMARC propres : passage à . Au bout de 8-12 semaines : .\r\n--\r\n\r\n17. Annexes : commandes utiles\r\n\r\n\r\n\r\nOutils web à mettre en favoris\r\nhttps://www.mail-tester.com/ — score sur 10\r\nhttps://internet.nl/mail/ — audit complet\r\nhttps://mxtoolbox.com/SuperTool.aspx — DNS, blacklists\r\nhttps://dmarcian.com/dmarc-inspector/ — vérif DMARC\r\nhttps://www.kitterman.com/spf/validate.html — vérif SPF\r\nhttps://postmaster.google.com/ — Google Postmaster\r\nhttps://senderscore.org/ — réputation IP\r\n\r\nDocumentation de référence\r\nISPmail / Workaround.org — https://workaround.org/ispmail/ — le tutoriel le plus complet et tenu à jour, par version Debian.\r\nMailcow docs — https://docs.mailcow.email/ — pour la version conteneurisée clé-en-main.\r\nPostfix officiel — https://www.postfix.org/documentation.html\r\nRspamd docs — https://www.rspamd.com/doc/\r\nRFCs essentielles** : 5321 (SMTP moderne), 7208 (SPF), 6376 (DKIM), 7489 (DMARC), 8461 (MTA-STS), 8460 (TLS-RPT), 7672 (DANE-SMTP), 8058 (One-Click Unsubscribe).\r\n--\r\n\r\nL'auto-hébergement mail en 2026 reste possible, mais c'est devenu un sport : les règles changent, les gros acteurs durcissent leurs critères, et l'écosystème pousse vers la centralisation. Si tu réussis le warmup et tiens 6 mois sans incident, tu as gagné — mais ne baisse pas la garde, un changement unilatéral de Google peut survenir à tout moment, comme en février 2024."},{"uuid":"c8fa250e-d8b5-453a-a06a-799d53c3b6d1","slug":"la-smart-brick-de-lego-quand-la-brique-devient-intelligente","title":"LEGO : La brique qui répond","category":"loisirs","author":"cedric@abonnel.fr","cover":"cover.jpg","published":true,"published_at":"2026-01-13 20:26","created_at":"2026-01-13 20:26:53","updated_at":"2026-05-11 22:45:23","tags":[],"plain":"La brique qui répond\r\n\r\nÀ première vue c'est une brique LEGO comme une autre. Un parallélépipède de plastique gris, le format classique, deux par quatre tenons sur le dessus. On pourrait la prendre, l'emboîter dans un mur, et ne rien remarquer. Sauf que celle-là parle. Elle fait du bruit, elle clignote, elle sait si vous la secouez ou si vous la posez à plat. À l'intérieur, LEGO a réussi à caser un accéléromètre, un capteur de lumière, un capteur de couleur, un haut-parleur miniature et une puce sur mesure plus petite qu'un seul tenon. C'est la LEGO Smart Brick, et elle est arrivée en boutique le 1ᵉʳ mars 2026.\r\n\r\nIl faut tout de suite tordre le cou à un malentendu. La Smart Brick, ce n'est pas un Mindstorms. Ce n'est pas du LEGO éducatif, ce n'est pas une plateforme pour apprendre à coder, et on ne programme rien du tout avec. C'est un objet beaucoup plus simple dans son intention : faire en sorte qu'un set LEGO réagisse quand on joue avec. Vous prenez le X-Wing de Luke Skywalker, vous le faites basculer pour décoller, le brique embarquée détecte le mouvement et joue le bruit du moteur. Vous posez la minifigurine de Dark Vador à côté, la brique la reconnaît grâce à un Smart Tag (une petite tuile codée), et elle déclenche la respiration emblématique du Seigneur Sith. C'est tout. Mais c'est déjà beaucoup.\r\n\r\nLEGO appelle cet écosystème Smart Play. Il repose sur trois éléments. La Smart Brick elle-même, qui est le cerveau et le haut-parleur. Les Smart Tags, des tuiles plates qu'on accroche aux constructions et qui disent à la brique ce qu'elle doit faire à cet endroit (« ici tu joues un bruit de tir laser », « ici tu fais le bruit du réacteur »). Et les Smart Minifigures, des figurines avec un identifiant intégré, que la brique détecte quand on les approche. Le tout communique en local, sans appli obligatoire, sans écran, via un système maison que LEGO a baptisé BrickNet. C'est important : le pari est explicitement de faire de la techno invisible, pas de coller un smartphone entre l'enfant et le jouet.\r\n\r\nCôté pratique, la brique se recharge sans fil. Elle tient environ deux heures et demie en jeu actif, se met en veille au bout de trois minutes d'inactivité et se réveille quand on la secoue. Au-delà d'une dizaine d'heures de veille, il faut la remettre sur son chargeur. Une application gratuite, LEGO SMART Assist, sert à régler le volume, donner un nom à ses briques, gérer plusieurs appareils, et surtout mettre à jour le firmware — parce que oui, une brique LEGO peut maintenant recevoir des mises à jour logicielles. On y est.\r\n\r\nPour le lancement, LEGO a choisi Star Wars, et l'offre est un peu plus subtile qu'il n'y paraît. Huit sets sortent le 1ᵉʳ mars, mais seulement trois contiennent réellement une Smart Brick. Ce sont les coffrets dits All-In-One, qui embarquent la brique, son chargeur, des tags et des figurines intelligentes :\r\n75421 — Chasseur TIE de Dark Vador : 69,99 €, le ticket d'entrée.\r\n75423 — Le X-Wing rouge de Luke Skywalker : 89,99 €.\r\n75427 — Duel dans la salle du trône & A-Wing : 159,99 €, le plus gros, avec deux Smart Bricks.\r\n\r\nLes cinq autres sets — Millennium Falcon, Mos Eisley Cantina, AT-ST Endor, hutte de Yoda, Landspeeder de Luke — sont étiquetés Smart Play mais ne contiennent pas de brique. Ils embarquent juste des tags et des figurines compatibles. Pour qu'ils s'animent, il faut posséder une brique achetée dans l'un des trois coffrets All-In-One, et la déplacer d'un set à l'autre. C'est un choix commercial qu'on peut critiquer : un parent ou un grand-parent qui voit Smart Play sur la boîte de la Mos Eisley Cantina à 79,99 € a de quoi être surpris en rentrant à la maison.\r\n\r\nGéographiquement, le lancement est restreint. Six pays seulement à l'ouverture : États-Unis, Royaume-Uni, France, Allemagne, Pologne, Australie. Le reste du monde attendra.\r\n\r\nPourquoi est-ce intéressant au-delà du cas Star Wars ? Parce que LEGO ne fait pas ça pour vendre trois sets. La marque parle de plus de vingt brevets déposés sur la techno, et de la « plus grande évolution du système LEGO depuis l'introduction de la minifigurine en 1978 ». Le ton est ambitieux, et il y a déjà des rumeurs de déclinaisons sur les gammes Pokémon et Animal Crossing. Si le pari réussit, on parle d'une plateforme qui peut s'étendre à toute la production LEGO sur dix ou vingt ans. Si elle échoue, ce sera la deuxième tentative ratée après les Mindstorms et la gamme Boost, dans la longue liste des essais LEGO pour marier l'électronique au plastique.\r\n\r\nLe point qui me semble vraiment réussi, c'est la philosophie sans écran. Là où la plupart des jouets connectés exigent une tablette pour fonctionner, où l'enfant finit en pratique à regarder un iPad plutôt qu'à jouer avec l'objet physique, LEGO a fait le choix inverse : l'application existe mais elle est facultative, toute l'interaction se passe entre les mains et les briques. C'est moins spectaculaire dans une démo marketing, mais c'est probablement plus juste pour des gamins de huit ans.\r\n\r\nReste à voir ce que ça donne en vrai, sur le tapis du salon, après six mois d'utilisation, quand la batterie sera moins fringante et que la nouveauté se sera émoussée. C'est toujours là que se joue la vraie partie pour ce genre de produit. Mais sur le papier, et c'est rare, LEGO a sorti quelque chose qui ne ressemble à rien d'autre."},{"uuid":"5a0cced3-40d0-46bf-8501-b533f3c2608e","slug":"reparer-une-instance-uptime-kuma-installee-via-le-script-proxmox","title":"Réparer une instance Uptime Kuma installée via le script Proxmox","category":"informatique","author":"cedric@abonnel.fr","cover":"cover.svg","published":true,"published_at":"2025-11-26 08:33","created_at":"2025-11-26 08:33:49","updated_at":"2026-05-12 09:16:00","tags":[],"plain":"Méthode basée sur l'installation via le script communautaire :\r\ncommunity-scripts.github.io/ProxmoxVE/scripts?id=uptimekuma\r\n\r\nSi tu utilises Uptime Kuma pour monitorer ton infra, tu finiras tôt ou tard par tomber sur un de ces grands classiques : le service qui refuse de démarrer après une mise à jour, des erreurs SQLite louches dans , ou pire — l'interface qui tourne mais ne remonte plus aucun heartbeat. Dans 90 % des cas, c'est la base SQLite qui a pris cher, souvent à cause d'un arrêt brutal du conteneur LXC ou d'une migration qui s'est mal passée.\r\n\r\nAvant de paniquer et de tout réinstaller, il y a une série d'étapes à dérouler. Je les mets ici dans l'ordre, parce que l'ordre compte : on commence toujours par le moins destructif.\r\n\r\nPourquoi SQLite et pas un vrai SGBD ?\r\n\r\nPetite parenthèse pour les juniors qui se demanderaient. Uptime Kuma embarque SQLite parce que c'est une appli pensée pour être facile à déployer : pas de serveur de base à installer à côté, pas de credentials à gérer, juste un fichier sur le disque. C'est génial pour démarrer, mais ça a un défaut majeur — SQLite n'aime pas du tout être coupé en plein milieu d'une écriture. Si ton LXC tombe pendant que Kuma écrit un heartbeat, tu peux te retrouver avec un fichier corrompu. D'où l'importance de toujours arrêter proprement le service avant de toucher au fichier.\r\n\r\n1. Arrêter le service proprement\r\n\r\n\r\n\r\nC'est la première chose à faire, toujours. Tant que le service tourne, il a un verrou sur et il continue d'y écrire. Tu peux ouvrir le fichier en lecture avec malgré ce verrou, mais dès que tu veux faire un ou un , tu vas soit avoir une erreur , soit — pire — corrompre encore plus la base si tu forces.\r\n\r\nVérifie que c'est bien arrêté avant de continuer :\r\n\r\n\r\n\r\nTu dois voir . Pas , pas , pas avec un process encore en l'air.\r\n\r\n2. Aller dans le dossier de l'app\r\n\r\nLe script communautaire installe Kuma dans :\r\n\r\n\r\n\r\nDans ce dossier, ce qui nous intéresse c'est le sous-dossier . C'est là que vit tout ce qui compte : le fichier (la base), les uploads, et quelques fichiers de config. Le reste (, , etc.) c'est le code de l'application — tu peux le casser, un ou une réinstallation le remettra en place. Mais , si tu le perds, tu perds toute ta config de monitoring.\r\n\r\n3. Sauvegarder avant de toucher à quoi que ce soit\r\n\r\nRègle d'or de l'ops : on ne touche jamais à une base de données sans avoir une copie au chaud. Jamais.\r\n\r\n\r\n\r\nLe te génère un suffixe du genre . Comme ça si tu fais plusieurs interventions dans la même semaine, tu sais laquelle date de quand, et tu ne risques pas d'écraser une sauvegarde par une autre.\r\n\r\nCette copie embarque :\r\nla base elle-même\r\nles fichiers WAL (, ) si SQLite est en mode Write-Ahead Logging — c'est important de les prendre avec, sinon ta sauvegarde est incomplète\r\nles uploads et certificats si tu en as\r\n\r\nSi tu sautes cette étape et que tu te plantes à l'étape 5 ou 6, tu n'auras aucun moyen de revenir en arrière. Sérieusement, fais-le.\r\n\r\n4. Vérifier l'intégrité de la base\r\n\r\n\r\n\r\n, c'est la commande de diagnostic native de SQLite. Elle parcourt toute la base, vérifie que les index pointent bien sur les bonnes lignes, que les pages ne sont pas corrompues, que les contraintes sont respectées. Deux issues possibles :\r\n* : la base est saine sur le plan structurel. Si Kuma ne démarre toujours pas, le problème vient probablement d'une migration coincée (voir étape 5) ou du code de l'app, pas du fichier.\r\nUne liste d'erreurs : il y a de la corruption. Selon ce qui est touché, on passera à l'étape 5 ou 6.\r\n\r\nPour les juniors qui découvrent SQLite : , c'est le mot-clé que SQLite utilise pour les commandes qui ne sont pas du SQL standard — c'est spécifique à SQLite, tu ne le verras pas dans PostgreSQL ou MySQL.\r\n\r\n5. Supprimer un paramètre de migration corrompu\r\n\r\nSur certaines versions de Kuma (notamment autour des montées de version qui touchent à l'agrégation des heartbeats), il y a un bug connu : l'entrée dans la table se retrouve dans un état incohérent, et le service refuse de démarrer parce qu'il pense être au milieu d'une migration qui n'avance plus.\r\n\r\nLa fix :\r\n\r\n\r\n\r\nCe qu'on fait, c'est qu'on dit à Kuma : \"oublie où tu en étais, repars de zéro sur ce point\". Au redémarrage, il va recréer la clé proprement et relancer la migration depuis le début. C'est non destructif pour tes données de monitoring — on ne touche qu'à un drapeau d'état interne.\r\n\r\nSi ce n'est pas ton problème (clé absente ou suppression sans effet), passe à la suite.\r\n\r\n6. Solution radicale : vider la table \r\n\r\nSi la corruption est concentrée sur l'historique de monitoring (et c'est souvent le cas, parce que c'est la table où Kuma écrit le plus souvent — un INSERT toutes les 20-60 secondes par sonde, ça finit par faire du volume), tu peux la vider :\r\n\r\n\r\n\r\nÀ lire attentivement : cette commande supprime tout l'historique des sondes. Tu perds les graphes de uptime, les SLA calculés sur les 30/90/365 derniers jours, tout. En revanche :\r\ntes sondes sont conservées (table )\r\ntes utilisateurs aussi (table )\r\ntes notifications également (table )\r\nta config générale est intacte (table )\r\n\r\nC'est à utiliser uniquement quand :\r\npointe vers des problèmes sur ou ses index\r\nKuma refuse de démarrer et l'étape 5 n'a rien donné\r\nou plus simplement, ta base a tellement grossi que Kuma rame et que tu acceptes de perdre l'historique pour repartir propre\r\n\r\nTant qu'à faire, profites-en pour faire un derrière, qui va vraiment libérer l'espace disque (un seul ne récupère pas la place sur le disque, il marque juste les pages comme libres pour réutilisation) :\r\n\r\n\r\n\r\n7. Redémarrer le service\r\n\r\n\r\n\r\nEt vérifie qu'il a bien démarré :\r\n\r\n\r\n\r\nTu dois voir . Si tu vois ou si le service redémarre en boucle, ne le laisse pas dans cet état — passe directement à l'étape 8 pour comprendre pourquoi.\r\n\r\n8. Lire les logs\r\n\r\n\r\n\r\nLe cible le service, le fait du (équivalent de ) — les nouvelles lignes s'affichent en temps réel. Laisse tourner pendant deux ou trois minutes, le temps que Kuma rejoue ses migrations, recharge ses sondes, et envoie les premiers heartbeats.\r\n\r\nCe qu'il faut chercher dans les logs :\r\nerreurs SQLite : , , — ça veut dire que t'as encore un problème de fichier, voire de permissions\r\nmigrations bloquées : des messages du genre qui ne sont jamais suivis d'un \r\npermissions : , — typiquement après une intervention faite en root sur des fichiers qui doivent appartenir à un autre utilisateur. Vérifie avec que les fichiers sont bien possédés par l'user qui fait tourner le service\r\nmodules Node manquants : — ça arrive après une mise à jour qui s'est mal passée. La fix, c'est généralement de relancer dans \r\nport déjà utilisé : — tu as un autre process qui squatte le port 3001 (ou celui que tu as configuré)\r\n\r\nPour sortir du , c'est .\r\n\r\nEt après ?\r\n\r\nUne fois que Kuma tourne propre, prends cinq minutes pour mettre en place ce qui t'aurait évité d'arriver ici :\r\n\r\n1. Une sauvegarde régulière de . Un simple cron qui fait du dossier vers un autre serveur, ça suffit largement pour un Kuma perso. Pense à arrêter le service avant le tar, ou utilise qui fait un snapshot cohérent sans devoir couper Kuma.\r\n2. Un monitoring du monitoring. Oui, c'est méta. Mais si Kuma tombe, c'est lui qui t'aurait alerté de la chute de tes autres services — donc personne ne te prévient. Un check externe (UptimeRobot gratuit, healthchecks.io, ou un autre Kuma sur une autre machine) qui ping ton instance, c'est cinq minutes à mettre en place.\r\n3. Garder ta sauvegarde au moins une semaine** avant de la supprimer. Au cas où un effet de bord apparaîtrait quelques jours plus tard.\r\n\r\nEt voilà. Avec ces huit étapes, tu couvres 95 % des cas de Kuma cassé. Pour les 5 % restants — typiquement quand le LXC lui-même a un souci de filesystem — c'est une autre histoire, et il faudra sortir l'artillerie côté Proxmox."},{"uuid":"5982deaf-f3de-4f65-9270-9849132e64f6","slug":"nos-donnees-a-l-ere-de-l-ia-l-affaire-linkedin-et-la-colere-des-utilisateurs","title":"Nos données à l’ère de l’IA : l’affaire LinkedIn et la colère des utilisateurs","category":"actualité","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2025-11-05 07:10:37","created_at":"2025-11-05 07:10:37","updated_at":"2025-11-05 07:10:37","tags":[],"plain":"Un matin d’automne, Léa ouvre son compte LinkedIn comme elle le fait chaque jour. Consultante indépendante, elle y partage des réflexions sur le travail à distance, y échange avec des collègues et y recrute parfois des partenaires. Rien de bien extraordinaire. Mais ce jour-là, un post attire son attention : « LinkedIn utilise vos données pour entraîner ses IA ».\r\n\r\nAu début, elle croit à une rumeur. Encore une de ces tempêtes numériques qui s’évanouissent aussi vite qu’elles éclatent. Puis elle lit plus attentivement : le réseau professionnel de Microsoft admet effectivement utiliser certaines données publiques — les profils, les publications, les interactions visibles — pour nourrir ses modèles d’intelligence artificielle.\r\n\r\nDe la mise en relation à la collecte invisible\r\n\r\nDepuis sa création, LinkedIn se présente comme une vitrine professionnelle : un espace où chacun peut exposer son parcours, ses compétences, ses ambitions. En échange, la plateforme promet visibilité, opportunités et réseau. Mais derrière cette promesse, un autre marché s’est peu à peu installé : celui des données.\r\n\r\nChaque clic, chaque mise à jour de poste, chaque mot-clé devient une pièce d’un immense puzzle comportemental. Ce puzzle, jusqu’ici utilisé pour cibler des offres d’emploi ou des publicités, se retrouve désormais au cœur de quelque chose de beaucoup plus vaste : l’entraînement des intelligences artificielles.\r\n\r\nMicrosoft, maison mère de LinkedIn, investit des milliards dans l’IA. Or, pour qu’une IA apprenne, il lui faut une matière première : les mots, les textes, les interactions humaines. Et LinkedIn en regorge.\r\n\r\nLa ligne floue entre le “public” et le “privé”\r\n\r\nTechniquement, LinkedIn affirme ne collecter que les informations publiques. Mais qu’est-ce que cela signifie vraiment ? Léa n’a jamais donné son accord explicite pour que ses publications servent à entraîner des algorithmes de génération de texte. Elle les a partagées pour échanger avec des pairs, pas pour devenir une donnée parmi des millions d’autres.\r\n\r\nC’est là que le malaise grandit.\r\nLes utilisateurs découvrent que la frontière entre ce qu’ils publient volontairement et ce qui peut être réutilisé s’estompe. Dans les conditions d’utilisation, tout est mentionné — quelque part, en petits caractères. Mais rares sont ceux qui lisent jusqu’à la dernière ligne.\r\n\r\nLe choc du consentement absent\r\n\r\nLes réactions ne se font pas attendre : des posts indignés envahissent la plateforme même.\r\n« On n’est pas des cobayes ! » écrit un utilisateur.\r\n« Nos profils sont devenus des datasets », dénonce une autre.\r\n\r\nCe qui choque, ce n’est pas seulement l’usage, mais la manière dont il a été introduit : sans consultation, sans transparence, presque à bas bruit.\r\n\r\nLes défenseurs du projet rétorquent que l’IA ne “lit” pas nos données comme un humain. Qu’elle analyse des tendances, pas des personnes. Que tout est anonymisé.\r\nMais cette défense sonne creux pour beaucoup : anonymiser ne supprime pas la question éthique. À partir du moment où nos mots, nos idées, nos réflexions alimentent un système dont nous ne maîtrisons ni les usages ni les bénéfices, une part de notre autonomie numérique s’érode.\r\n\r\nUne affaire de confiance\r\n\r\nLinkedIn n’est pas la première plateforme à faire face à cette controverse. Reddit, X (ex-Twitter) et même Meta ont adopté des politiques similaires, justifiant ces pratiques par la nécessité d’améliorer leurs modèles d’IA.\r\nMais LinkedIn occupe une place particulière : il s’agit du réseau professionnel par excellence. Ici, les utilisateurs partagent des informations sensibles — leur parcours, leur entreprise, leurs compétences — souvent avec leur vrai nom.\r\n\r\nLa relation de confiance entre l’utilisateur et la plateforme est donc essentielle. Et c’est justement cette confiance qui vacille.\r\n\r\nLéa et le dilemme numérique\r\n\r\nQuelques jours plus tard, Léa se rend dans les paramètres de confidentialité.\r\nElle découvre, cachée dans une section sobrement intitulée « Utilisation des données pour l’IA », une mention : « Nous pouvons utiliser vos informations publiques pour améliorer nos produits et services, y compris les technologies d’intelligence artificielle. »\r\n\r\nIl existe bien une option d’exclusion, mais difficile à trouver. Léa la décoche, sans savoir si cela changera vraiment quelque chose.\r\nElle ressent un mélange de soulagement et de résignation.\r\n\r\nCar au fond, la question dépasse LinkedIn. Elle touche à une réalité plus vaste : dans l’ère de l’intelligence artificielle, nos données sont devenues la nouvelle énergie, le carburant invisible qui alimente des machines toujours plus puissantes.\r\n\r\nVers une prise de conscience collective\r\n\r\nL’affaire LinkedIn agit comme un électrochoc. Elle révèle à quel point le consentement numérique reste un concept fragile, souvent illusoire. Elle invite chacun à repenser ce qu’il partage en ligne, mais aussi à exiger des plateformes une vraie transparence.\r\n\r\nLes régulateurs européens, via le RGPD, commencent à se saisir du sujet. Certains experts appellent à créer un « droit à l’exclusion des IA », un cadre légal obligeant les entreprises à obtenir un consentement explicite avant toute utilisation des données à des fins d’entraînement algorithmique.\r\n\r\nMais pour l’instant, la balle reste surtout dans le camp des utilisateurs — ceux qui, comme Léa, naviguent entre pragmatisme et inquiétude, entre le besoin de visibilité et la peur d’être instrumentalisés.\r\n--\r\n\r\n Entre progrès et perte de contrôle\r\n\r\nL’IA promet des avancées spectaculaires. Elle transforme nos métiers, nos outils, nos manières de communiquer. Mais elle pose une question fondamentale : qui possède les données qui la nourrissent ?\r\n\r\nLinkedIn n’est peut-être qu’un exemple parmi d’autres, mais il symbolise un tournant.\r\nDans cette ère où chaque mot que nous tapons peut devenir une donnée d’apprentissage, la véritable ressource n’est plus la technologie, mais la confiance.\r\nEt cette confiance, aujourd’hui, semble s’effriter à mesure que les algorithmes se renforcent.\r\n--\r\n\r\nVoici les risques autour de l’utilisation des données des utilisateurs par LinkedIn (et d’autres plateformes) pour l’IA\r\n\r\n1. Atteinte à la vie privée et au consentement\r\n\r\nMême si LinkedIn affirme n’utiliser que des données “publiques”, cela ne signifie pas que les utilisateurs ont consenti explicitement à cet usage.\r\n\r\n Les informations partagées à des fins professionnelles (CV, publications, commentaires) peuvent être réutilisées hors contexte.\r\n Le consentement est souvent implicite, enfoui dans les conditions d’utilisation.\r\n L’utilisateur perd le contrôle sur ce qu’il partage : il ne sait pas exactement comment ni par qui ses données seront exploitées.\r\n\r\n➡️ Exemple concret : ton texte sur la gestion d’équipe pourrait servir à entraîner une IA d’entreprise sans que tu le saches, ni que ton nom y soit associé.\r\n--\r\n\r\n2. Profilage et reconstitution d’identité\r\n\r\nL’agrégation massive des données permet aux IA d’identifier des schémas comportementaux et professionnels :\r\n\r\n Les algorithmes peuvent déduire des informations sensibles (habitudes de travail, orientation politique, situation financière, etc.) à partir de simples interactions.\r\n Ces profils peuvent être utilisés pour le ciblage commercial, le recrutement automatisé, voire l’évaluation de performance dans certains contextes.\r\n\r\n➡️ Risque : un recruteur ou un système d’IA pourrait juger ton profil ou ton style d’écriture sans ton accord.\r\n--\r\n\r\n3. Appropriation intellectuelle et perte de la valeur de ton contenu\r\n\r\nLes textes, publications et commentaires des utilisateurs servent de matière première à l’entraînement de modèles d’intelligence artificielle.\r\n\r\n Tes contributions (même originales ou expertes) peuvent être intégrées à des IA génératives qui, ensuite, produiront du contenu similaire sans mentionner leur source.\r\n Cela pose une question d’éthique et de propriété intellectuelle : tu deviens fournisseur involontaire de savoir gratuit.\r\n\r\n➡️ Exemple : une IA générative pourrait reformuler ou réutiliser tes analyses dans un contexte commercial sans te citer.\r\n--\r\n\r\n4. Risque de réidentification\r\n\r\nMême si LinkedIn ou Microsoft annoncent que les données sont “anonymisées”, des études montrent qu’il est souvent possible de réidentifier des individus à partir de fragments de données combinées.\r\n\r\n Les publications, les dates d’emploi ou les noms d’entreprises peuvent suffire à retrouver une personne réelle.\r\n Cela peut exposer à du harcèlement, du doxing (divulgation d’infos perso) ou du recrutement non sollicité.\r\n--\r\n\r\n5. Érosion de la confiance numérique\r\n\r\nChaque nouvelle utilisation non transparente des données creuse le fossé entre utilisateurs et plateformes.\r\n\r\n Les professionnels peuvent se censurer, publier moins, ou quitter la plateforme.\r\n Cela nuit à la qualité du réseau et à la diversité des échanges.\r\n\r\n➡️ Risque collectif : LinkedIn perd son rôle de réseau professionnel ouvert, et les utilisateurs deviennent méfiants ou silencieux.\r\n--\r\n\r\n6. Exploitation commerciale asymétrique\r\n\r\nLes utilisateurs fournissent la matière (leurs données), mais ne bénéficient pas des revenus générés par les IA entraînées sur ces données.\r\n\r\n Les plateformes en tirent un profit direct (via les produits IA, la publicité ou les abonnements premium).\r\n Les utilisateurs, eux, deviennent des ressources gratuites sans contrepartie.\r\n--\r\n\r\n7. Sécurité des données à long terme\r\n\r\nUne fois intégrées dans des modèles d’IA, les données ne peuvent pas toujours être effacées.\r\n\r\n Même si tu supprimes ton compte, l’empreinte de tes données peut subsister dans les systèmes d’apprentissage.\r\n Cela entre en tension avec le droit à l’oubli, garanti par le RGPD.\r\n--\r\n\r\nExemples concrets et projections permettant de bien mesurer les conséquences réelles (et à venir) de cette collecte de données par LinkedIn et les IA associées.\r\nVoici une série d’illustrations réalistes, plausibles et documentées, suivies de projections futures si la tendance se poursuit.\r\n\r\n💼 1. Exemple actuel : ton profil devient un “modèle” de compétence\r\n\r\nUn consultant publie régulièrement des analyses sur la transformation digitale. Ses posts sont publics, bien écrits et souvent partagés.\r\n👉 Ces textes peuvent être intégrés (sans qu’il le sache) dans des ensembles de données qui servent à entraîner une IA professionnelle de rédaction ou de recrutement.\r\nRésultat : une IA générative pourrait ensuite produire des articles ou des messages LinkedIn similaires au sien, imitant son ton et sa structure — sans jamais le créditer.\r\n\r\n📍 Projection 2026 : les entreprises paieront pour des outils d’IA “experts en communication LinkedIn”, entraînés sur des millions de publications d’utilisateurs. Ces contenus originaux deviendront des modèles commerciaux... sans rémunération pour leurs auteurs.\r\n--\r\n\r\n🔍 2. Exemple : profilage algorithmique dans le recrutement\r\n\r\nLinkedIn est déjà utilisé pour le tri automatisé des candidatures. En combinant ces données avec des modèles d’IA, une entreprise pourrait prédire les “traits de personnalité” d’un candidat à partir de son profil, de son vocabulaire ou de son historique de publications.\r\n\r\n➡️ Risque concret :\r\nUne IA pourrait écarter un profil jugé “instable” ou “non aligné culturellement” simplement parce qu’elle a repéré des posts critiques sur le management — sans intervention humaine.\r\n\r\n📍 Projection 2027 : des recruteurs utilisent des IA pour “noter” automatiquement les profils selon leur probabilité de succès dans une entreprise, créant des discriminations invisibles et difficilement contestables.\r\n--\r\n\r\n✍️ 3. Exemple : appropriation intellectuelle déguisée\r\n\r\nImaginons une chercheuse en RH qui publie des posts détaillant sa méthode d’évaluation des compétences.\r\nQuelques mois plus tard, une IA professionnelle (issue d’un modèle Microsoft ou OpenAI) reprend des formulations et des idées très proches dans un produit commercial.\r\n\r\n➡️ Risque : sa méthode devient une fonctionnalité d’un logiciel RH, sans reconnaissance ni rémunération.\r\n\r\n📍 Projection 2028 : les IA intègrent massivement du contenu “crowdsourcé” depuis LinkedIn, Reddit ou Medium. Les créateurs deviennent fournisseurs involontaires de savoir, pendant que les entreprises vendent des outils basés sur leurs contributions.\r\n--\r\n\r\n🧠 4. Exemple : inférences comportementales non désirées\r\n\r\nUne IA peut déduire plus que ce que l’utilisateur pense partager.\r\n➡️ Par exemple :\r\n\r\n Un rythme de publication irrégulier peut être interprété comme un “manque de disponibilité”.\r\n Un enchaînement de changements de poste peut être lu comme un “instinct d’instabilité”.\r\n Le ton ou la fréquence des commentaires peut servir à classer les utilisateurs selon leur “influence sociale”.\r\n\r\n📍 Projection 2026-2030 : ces données comportementales nourrissent des scores de réputation professionnelle invisibles, que certaines entreprises ou plateformes utilisent pour classer les candidats, partenaires ou clients potentiels.\r\n--\r\n\r\n💰 5. Exemple : création de produits IA entraînés sur les utilisateurs\r\n\r\nMicrosoft développe des outils d’IA intégrés à LinkedIn Learning ou à Microsoft 365 Copilot.\r\n➡️ Les modèles peuvent s’inspirer des tendances, expressions et structures de pensée des utilisateurs LinkedIn pour proposer des conseils personnalisés (“Voici comment rédiger une offre d’emploi efficace”).\r\n\r\n📍 Projection 2030 :\r\nLes modèles d’IA deviennent si performants qu’ils proposent des stratégies RH, des analyses de marché ou des lettres de motivation entières, entraînées sur les contenus des utilisateurs — mais commercialisées sous licence Microsoft.\r\nLes utilisateurs deviennent littéralement la matière première de produits IA vendus à d’autres professionnels.\r\n--\r\n\r\n🔒 6. Exemple : difficulté d’effacement ou de contrôle\r\n\r\nUn utilisateur décide de supprimer son compte LinkedIn.\r\n➡️ Problème : ses anciens posts, déjà utilisés pour l’entraînement de modèles, ne peuvent pas être “désappris” par ces IA.\r\nLes traces textuelles persistent dans les modèles, parfois indéfiniment.\r\n\r\n📍 Projection 2029 : même avec le droit à l’oubli renforcé, la récupération complète des données dans les modèles devient quasi impossible. Les régulateurs européens devront imposer des procédures d’“oubli algorithmique”, très coûteuses à mettre en œuvre.\r\n--\r\n\r\n🌍 7. Projection sociétale globale : le paradoxe de la transparence\r\n\r\nÀ long terme, la généralisation de ces pratiques pourrait produire un effet de censure douce :\r\n\r\n Les utilisateurs partagent moins d’analyses authentiques, de peur d’être copiés ou profilés.\r\n Les publications deviennent plus neutres, plus polies, moins spontanées.\r\n Le réseau perd de sa valeur humaine et se transforme en vitrine aseptisée.\r\n\r\nEn parallèle, les grandes entreprises technologiques accumulent des quantités massives de données textuelles qui leur donnent un avantage compétitif durable**.\r\nLes utilisateurs, eux, deviennent invisibles dans la chaîne de valeur de l’intelligence artificielle."}] |