Jérôme Flesch a écrit 390 commentaires

Je ne parle pas de TCO, parce que c'est très difficile à évaluer, et surtout, pour moi, c'est totalement hors-sujet.

C'est difficile à évaluer :

J'ai une utilisation modeste de l'IA. Contrairement à ce que certains semblent supposer, ma machine ne tourne pas 24/24. Elle est allumée quand j'en ai besoin (soit quelque-part entre 4h et 10h par jour), et elle est idle une grosse partie du temps à ~100W. J'ai une prise intelligente branchée dessus, donc si ça intéresse des curieux, je pourrais vous faire un retour sur le coût de l'électricité dans quelques mois.

Et c'est tout aussi difficile à comparer au cloud : Pour quelqu'un comme moi qui a une utilisation modeste de l'IA, ça peut remplacer complètement un abonnement Claude. Pour des gens qui vibe-sloppent, il leur faudrait sûrement garder leur abonnement, mais ils pourraient peut-être s'en servir pour passer du max (90€/mois) au pro (18€/mois) ?

Et est-ce qu'une Intel Arc Pro B60/B70 ne pourrait pas suffire à ces gens ? Auquel cas, le TCO devient probablement beaucoup plus raisonnable. Mais ça dépend toujours des gens et de leur façon de travailler, donc c'est tout aussi difficile à dire.

Et c'est totalement hors-sujet pour moi :

Je ne fais pas ce montage pour faire des économies. Je fais ce montage parce-que j'ai une sainte horreur de tout ce qui est cloud, et parce-que le sujet m’intéresse particulièrement.

Concernant le futur des modèles openweight :

Anthropic n'a jamais distribué aucun modèle openweight à ma connaissance.

En terme de modèles récents, le seul d'OpenAI est gpt-oss, mais il n'a pas beaucoup marqué les mémoires.

De plus, Gemma est fait par Google, pas par une boite chinoise. Je suspecte qu'ils font ces modèles en anticipation du jour où les téléphones Android seront capables de les faire tourner.

À noter que les premiers modèles open-weight furent quasiment tous américains (GPT-1, GPT-2, llama2, etc). Ce ne sont pas les chinois qui ont lancé cette tendance. Il est aussi intéressant de noter que Mistral, notre (seul) champion français, ouvre aussi généralement les poids de ses modèles.

Ce n'est donc pas une tendance nouvelle, et je doute qu'elle soit temporaire. Sinon le patron d'Anthropic ne s'embêterait pas à activement de lutter contre.

Alors, je viens de regarder: pour une deuxième alimentation, il faut un petit module "add2psu".

D'ailleurs, je viens de refaire mes calculs, et si je veux monter à 6 GPU sans risquer de faire cramer mon alimentation, il va me falloir une deuxième alimentation. Donc je vais devoir tester les add2psu.

J'espère bien que tout le monde ne va pas faire pareil ! On est bien d'accord que ça serait une catastrophe. Déjà rien que les IA en datacenter promettent d'être un cauchemar écologique.

Pour le coup, c'est un montage somme toute très compliqué à faire, matériellement et logiciellement. C'est clairement un projet de passionné. Je ne me suis pas imaginé à un seul moment que quelqu'un de non-passionné puisse vouloir faire ça.

Je le partage ici surtout pour éviter à d'autres passionnés des erreurs que j'ai pu faire ou que j'aurai pu faire (d'autant plus important qu'il y a un risque incendie non-négligeable sur ce genre de montage). Je suppose aussi que pour les non-passionnés, c'est juste intéressant de voir ce l'auto-hébergement d'IA peut nécessiter.

Pour le futur, mon espoir est que les prix du matériel reviennent à une certaine normalité, et que la capacité du matériel permette de faire tourner les IA auto-hébergeables d'aujourd'hui sur une seule carte graphique de demain. Ceci dit, vu la tournure des évènements, je n'y crois pas trop.

Les alimentations 1200W et 1500W viennent normalement avec suffisamment de connecteurs.

Je déconseille les splitters sur les câbles d'alimentation. Le risque de dépasser le maximum accepté par le connecteur initial est non-négligeable.

À défaut, je recommande plutôt de mettre en place une deuxième alimentation. Je sais que c'est faisable parce-que les mineurs de cryptomonnaie l'ont souvent fait. Mais comme j'ai eut la chance de trouver une bonne alimentation de 1500W, je n'ai pas creusé plus le sujet. Si on part sur cette option, il faut surtout faire très attention à ne pas dépasser la capacité du réseau électrique domestique (fusible, prise, multi-prise), et à toujours garder en tête que les puissances maximum indiquées sont des maximum en pic, pas en consommation continue.

Le temps de calcul où le modèle évalue le prompt, c'est le temps de lecture, aussi appelé pré-remplissage (prefill). À ma connaissance, c'est exactement la même procédure, et donc la même vitesse, pour lire un contexte depuis le début, que pour lire une phrase de 10 mots écrite par l'utilisateur après coup pendant la conversation.

C'est tout à fait possible. Je n'ai pas de carte AMD, donc je ne peux pas tester de mon côté.

Quand j'ai écris "généralement plus lent", je me suis basé sur mon expérience avec la Intel B60 et sur ce que j'ai pu lire dans divers commentaires sur divers sites. J'ai peut-être fait une généralisation hâtive sur ce coup-là :/

Ça serait plutôt l'écriture de nouvelles ça.
Pour le jeu de rôle, il s'agit de demander au LLM de soit jouer le rôle du Maître du Jeu, soit le rôle d'un autre personnage, soit les deux.

Pour avoir essayé le vibe-coding, c'est exactement mon expérience. Le vibe-coding donne trop vite des résultats. C'est impossible de se motiver à relire sérieusement ce que génère l'IA. On veut juste sa dose de dopamine suivante le plus vite possible.

Et en parlant d'expérience, à force de vibe-coder, la perte de compétences va être brutal chez certains.

Moi qui en avait déjà ras-le-bol de devoir repasser régulièrement derrière les collègues pour nettoyer leur travail bâclé, v'là que ça va pas râter, je vais devoir repasser derrière leurs IAs …

nvidia tesla k80

Elles sont compliquées à refroidir correctement. Elles ne sont plus supportées par les pilotes Nvidia depuis mi-2024 (pilote 470 il me semble). Et comme gUI l'a fait remarquer, comparé aux dernières générations de GPU, elles ont maintenant autant de puissance de calcul qu'une pomme de terre mal-cuite.

Et les H100 à moins 600€, faut me dire où ! C'est l'occasion de devenir riche ! :-)

C'est une remarque intéressante. Ceci dit, pour ma part, j'ai l'impression que c'est plutôt l'inverse. Je pense que l'entrisme est plutôt du coté des LLMs cloud.

Les LLMs cloud sont nettement plus accessibles et faciles à utiliser que les LLMs auto-hébergés. Le prix d'entrée des LLMs cloud est nettement plus bas aussi. Les LLMs auto-hébergés sont, eux, très difficiles à mettre en place de façon viable. D'ailleurs, je viens d'acheter deux cartes Intel Arc Pro B60, et j'ai encore envie d'hurler tellement elles sont ridiculement difficiles à utiliser pour faire tourner des LLMs.

Mais comme mentionné, les LLMs cloud ont des limitations tarifaires. Je pense que c'est surtout ces limitations qui vont pousser les gens qui ont une utilisation plus intense des LLMs vers les LLMs auto-hébergés. Je suppose que la plupart feront alors, comme moi, un mix des deux : LLMs auto-hebergés pour ce qu'ils savent faire, et occasionnellement LLMs cloud pour les tâches qui demandent un peu plus d'intelligence ou de fiabilité.

De ce que j'en comprends, SLI et Crossfire ont été abandonné. Les jeux n'exploitent plus qu'une seule carte vidéo.

Pour le gain de perf, d'après ce que je comprends, ça dépend de ton moteur d'inférence.

llama.cpp est bête et méchant: il met les N premières couches du réseau de neurones sur une carte graphique, les N couches suivantes sur une autre carte graphique, etc. Et pour chaque token, il interroge chaque carte graphique, les unes après les autres. Du coup, il y a un gain de perf que lorsqu'il y a plusieurs requêtes en parallèle. Mais sinon, il y a même un peu de perte de vitesse à cause du temps perdu à passer par le bus PCIe et le CPU entre chaque carte.

vLLM, lui distribue ça plus intelligemment : chaque couche est répartie entre les cartes graphiques --> toutes les cartes travaillent en parallèle et s'échangent, à chaque sortie de couche, une partie de leur résultat. Ça sollicite plus intensément le bus PCIe et le CPU, mais augmenter le nombre de GPU augmente les performances. Par contre, pour cette raison, vLLM est plus exigeant et préfère des cartes graphiques identiques. C'est pour ça que je n'ai pas pu l'utiliser efficacement sur mon montage.

La conso, ça dépend. Comme llama.cpp ne parallélise pas le calcul, tu n'as qu'une carte vraiment active à la fois. Je n'ai pas pu tester avec vLLM.

Intéressant. Je ne connaissais pas Hermes Agent.

Dans ma description, c'est un frontend. Au même titre que opencode ou openclaw (que j'ai oublié de mentionner d'ailleurs). Il interface le LLM avec le reste du monde, et lui met à disposition des outils.

Avec une bande passante de 120Go/s, il y a deux points qui vont déterminer la vitesse du LLM:

• La taille du LLM: un 20b en q4, c'est tout à fait modeste, sans non plus être tout petit.
• La taille du contexte / de la discussion : si le fonctionnement de Hermes Agent fait qu'il n'a pas à relire régulièrement une grosse discussion, ça peut fonctionner relativement vite.

Il faut aussi voir ce qu'on entend par "vitesse acceptable". Pour certaines utilisations, une lecture à 100 tokens/s et une génération à 3 tokens/s suffisent largement (ceux qui s'en servent dans des batchs par exemple). Pour d'autres utilisations comme la programmation agentique, ça serait totalement insuffisant.

car trop médiocres pour être réellement utiles

Je pense que c'est là où son avis et le mien diffèrent. Je suspecte qu'il parle de vibe-coding. Et comme je l'ai mentionné, vibe-coder avec un LLM auto-hébergé n'est pas une bonne expérience (ni avec un LLM cloud d'ailleurs). Mais il y a d'autres utilisations où un LLM auto-hébergé suffit. Ils ne seront clairement jamais aussi intelligents que les LLM cloud, mais ils sont suffisants.

Pour les LLMs réellement opensource, j'ai regardé, il y en a quelques-uns, par exemple OpenLlama. Mais ils sont clairement anecdotiques à ce stade.

Pour l’entraînement, on est d'accord.

Par curiosité, j'ai demandé à Claude si le supercalculateur Jean Zay pourrait entraîner assez facilement un modèle de 32 milliards de paramètres. Il dit que ça prendrait quelques semaines, et que c'est limite surdimensionné pour ce problème (je note d'ailleurs que "quelques semaines" est visiblement considéré comme rapide pour de l’entraînement). Par contre, il est déjà dépassé pour des modèles de la taille de Kimi K2.5 ou Claude Sonnet.

Sur un ordinateur simple, bien chargé en cartes graphiques, de ce que j'en comprends, le mieux qu'on puisse espérer entraîner from-scratch serait du 3 milliards.

And remember kids …

Si tu veux du vraiment très simple, autre que Ollama, et capable d'utiliser des modèles HuggingFace, je dirais: gpt4all.

Sinon, comme mentionné précédemment, llama-swap. Plus compliqué, mais plus versatile.

Ah et zut, pour le docker-compose.yml, j'ai oublié que j'avais customisé mon llama-swap. Du coup, le même, sans ma customisation:

services:
  llama.cpp:
    image: ghcr.io/mostlygeek/llama-swap:cuda
    restart: "always"
    runtime: nvidia
    ports:
      - "8123:8080"
    volumes:
      - /data/llama.cpp/models:/models
      - ./config.yaml:/app/config.yaml:ro
    deploy:
      resources:
        reservations:
          devices:
            - capabilities: [gpu]

Typo: je voulais parler de ministral-3 et non de mistral-3.

D'ailleurs, pour du role-play, je pense que tu peux commencer par essayer ministral-3-14b-q4. Au doigt mouillé, ça rentrera peut-être sur ton GPU.

Ah oui, aussi, pour savoir si ça rentre: sur l'interface web de llama-swap, tu peux filter les logs de l'"upstream" (llama-server) sur "GPU". Si toutes les layers sont sur le GPU, tu as gagné.

Sommaire

• Pourquoi la carte graphique est super duper importante ?
• La VRAM
• Les moteurs d'inférence
• Docker
• La taille du modèle
• La taille du contexte
• Du coup, avec 12Go de VRAM ?
• Dense ou Mixture-of-Expert
• La spécialisation du modèle
• Exemple de configuration llama-swap
• Où choper les modèles ?
• Et SillyTavern dans tout ça ?

Je vais mettre de coté de le coté porn pour me concentrer sur l'auto-hébergement de LLM et SillyTavern. Après, chacun est libre de faire ce qu'il veut, hein ;-)

TL;DR: avec 12Go de VRAM, ça risque d'être chaud.

Pourquoi la carte graphique est super duper importante ?

Le CPU est une puce relativement généraliste et optimisée pour la faible latence. Le GPU (le processeur de la carte graphique) est une puce spécialisée dans le calcul parallélisé massivement.

En gros, si le calcul était du transport de matériel, le CPU est un peu l'équivalent d'une voiture de course, là où le GPU est un camion. Et l'IA a besoin de camions.

La VRAM

Du coup, le point le plus important pour les LLM, et de très loin, c'est la VRAM (la RAM de la carte graphique). La VRAM va déterminer la taille du LLM que tu peux utiliser. Si tu tentes de charger un LLM trop gros pour ta VRAM, la plupart des outils comme llama.cpp, ollama, etc vont le faire déborder sur le CPU et la RAM. Ça va marcher, mais les performances vont s'effondrer très rapidement (ce que tu as observé).

Les moteurs d'inférence

Ollama, llama.cpp, llama-server, etc, sont des moteurs d'inférences.

J'ai longtemps utilisé Ollama (qui utilise llama.cpp), mais les dernières versions se révèlent de plus en plus décevantes: notamment, les derniers modèles mettent un temps fou à charger sur mon setup.

Actuellement, je recommanderais plutôt llama-swap (qui intègre llama-server, qui utilise llama.cpp).

Docker

Personnellement, je fais tourner mes moteurs d'inférence dans Docker.

J'utilise du matériel Nvidia. Et dans le cas du matériel Nvidia, ça complexifie plus que ça ne simplifie (il faut quand même installer Cuda, et il faut installer nvidia-container-toolkit). Par contre, ça permet quand même de passer d'un moteur à un autre facilement, et de ne pas saloper le système hôte.

Dans le cas des cartes AMD (Rocm) et Intel (sycl), je ne serai pas surpris si Docker simplifie pas mal les choses. Sauf erreur de ma part, pas besoin d'installer Rocm sur le système hôte. Il suffit de passer les devices dans le conteneur, et chaque conteneur intègre la version de Rocm dont il a besoin.

La taille du modèle

Là, on rentre dans le cœur du sujet.

Je vais sursimplifier à mort: chaque modèle a ses propres spécificités. Mais là, il s'agit juste de donner des points de repères.

Les caractéristiques les plus fréquentes sont:
- le nombre de paramètres
- la quantification
- dense ou mixture-of-experts

Le nombre de paramètres est actuellement en milliards pour les modèles self-hosted (les modèles cloud tapent les trilliards). Ça donne un ordre d'idée de la quantité de connaissances stockées dans le LLM, mais aussi plus ou moins de sa capacité de réflexion (<< attention, ceci est hyper approximatif !). Milliard est abrégé b en anglais. Donc des tailles classiques en LLM self-hosted, c'est, par exemple, 3b, 14b, 27b, 35b, etc.

La quantification, c'est la taille de chaque paramètre en mémoire. Les classiques sont:
- fp16: précision max. 2 octets par paramètre
- q8: 1 octet par paramètre
- q4: 1 octet pour 2 paramètres

Après il y a encore des variantes dans les quantifications (S, M, XL, etc), mais je ne vais pas détailler ça.

En gros, fp16, ça bouffe plein de VRAM, mais c'est la variante qui hallucinera le moins.
q8, on parle d'une précision de 99% par rapport à fp16. C'est généralement suffisant pour avoir un bon résultat. q4, on parle de ~97% par rapport à fp16. q4, ça fonctionne, mais on a parfois des surprises.

Il y a des quantifications en dessous de q4, mais je ne vais même pas en parler tellement les résultats sont médiocres.

À noter que, d'expérience, plus un modèle a de paramètres, plus il sera tolérant à la quantification. Par exemple, un 70b en q4 sera probablement aussi utilisable qu'un 14b en q8 (estimation au doigt mouillé sortie de mon chapeau magique).

Et donc là, on peut estimer au doigt mouillé la taille en VRAM du modèle:

nombre de paramètre × (quantification / 8)

La taille du contexte

Mais c'est pas tout ! Il faut aussi stocker en VRAM le contexte. Autrement dit, la discussion que l'utilisateur et le LLM sont en train d'avoir. Ce contexte est stocké dans le "KV cache". Pour des questions de performance, on doit déterminer dès le départ la taille maximum du contexte.

Cette taille est exprimée en tokens. Un token, c'est un mot, ou une syllabe, ou un symbole. Pour simplifier à mort, on peut considérer que c'est le nombre de mots.

Estimer la consommation en VRAM du KV cache est très délicat et dépend du modèle. Le plus simple à mon avis, c'est de juste essayer et voir si ça rentre.

Il est quantifié à fp16 par défaut, mais les moteurs d'inférence permettent maintenant de réduire ça. Personnellement, je le met en q8.

Il faut aussi penser à activer "Flash Attention". C'est une optimisation qui réduit considérablement la taille du KV cache pour les modèles qui la supporte. Bientôt devrait aussi arriver une nouvelle optimisation, "TurboQuant".

Un grand contexte est particulièrement nécessaire en programmation agentic (opencode, etc): il faut au moins un contexte de 64K, si pas 128K, pour que ce soit utilisable (sinon ça va recompresser le contexte constamment). Je soupçonne que c'est aussi particulièrement utile pour du role-play avec SillyTavern.

À noter que, par défaut, Ollama utilise un petit contexte de max 4K ou 8K si je me souviens bien. Suffisant pour une simple discussion. Insuffisant pour tout le reste. Il faut donc le régler.

Attention aux débordements ! L'effet sur les performances est sournois: si il y a débordement sur la RAM+CPU, une discussion courte n'utilisera qu'une petite partie du KV cache, et donc les performances ne seront que légèrement dégradées. Par contre, la dégradation va s'amplifier sévèrement avec la taille du contexte.

Du coup, avec 12Go de VRAM ?

Avec une carte graphique de 12Gb, tu peux déjà oublier fp16 et q8. Tu as des petits modèles qui rentrerait à cette quantification (du 3b et 7b par exemple), mais tu n'en tireras rien de bon. Donc ça sera forcément q4 pour toi.

Tu peux oublier l'idée de la programmation agentic: il faut des LLM d'au moins 27b, avec un gros contexte.

Pour le role-play avec SillyTavern, à essayer. Mais je ne pense pas que les petits modèles (≤14b) te donneront satisfaction.

Pour référence, j'ai 16+16+12Go de VRAM, et je fais tout juste rentrer qwen3.6-35b-a3b en q8 avec 128K de contexte.

Dense ou Mixture-of-Expert

Au début, il n'y avait des LLMs denses: quand on leur envoi une requête, une grande partie du réseau de neuronnes est utilisée. Puis sont arrivés les MoE (Mixture-of-Expert).

Un des 1er MoE open-weight correct est mixtral, de Mistral (cocorico ! :)

Un LLM MoE, c'est en fait un ensemble de sous-LLM spécialisés ("experts"). C'est un 1er réseau de neurones qui décide vers quel autre LLM envoyer la requête.

L’avantage: il n'y a qu'une sous-partie du LLM qui est active à la fois. Le GPU a nettement moins de calculs à faire. Ils sont donc nettement plus rapides.
L'inconvénient: les experts sont relativement petits, leurs connaissances sont moins entre-croisés, donc ils sont potentiellement plus bêtes.

Exemple:
- qwen-27b est dense
- qwen-35b-a3b est un MoE, avec max 3 milliards de paramètres actifs simultanément uniquement (autrement dit, des experts de 3 milliards de paramètres)

La spécialisation du modèle

Les LLMs self-hosted sont très limités en taille. Il y a donc des choix à faire quant à ce qu'on leur apprend.

Exemples:
- mistral-3 est un généraliste, mais qui sait suivre des instructions et utiliser des outils (mon préféré ;)
- qwen3-coder est spécialisé programmation
- qwen3.6 .. je ne suis pas sûr, mais il se débrouille très très bien en code. C'est probablement le meilleur à l'heure actuelle.

Exemple de configuration llama-swap

docker-compose.yml

services:
  llama.cpp:
    build: .
    restart: "always"
    runtime: nvidia
    privileged: true
    ports:
      - "8123:8080"
    volumes:
      - /data/llama.cpp/models:/models
      - /data/stable-diffusion.cpp/models:/models-sd
      - ./config.yaml:/app/config.yaml:ro
    deploy:
      resources:
        reservations:
          devices:
            - capabilities: [gpu]

config.yaml

models:
  Gemma4-q4-uncensored:
    cmd: >
      llama-server --port ${PORT} --jinja
      --ctx-size 131072 --flash-attn auto
      --cache-type-k q8_0
      --cache-type-v q8_0
      --model /models/gemma4/gemma-4-31B-it-uncensored-Q4_K_M.gguf
  Gemma4-q4:
    cmd: >
      llama-server --port ${PORT} --jinja
      --ctx-size 131072 --flash-attn auto
      --model /models/gemma4/gemma-4-31B-it-UD-Q4_K_XL.gguf
      --mmproj /models/gemma4/mmproj-BF16.gguf

Où choper les modèles ?

Ollama a très bien streamliné la récupération des modèles. Mais comme dit, je déconseille Ollama actuellement. En plus, le dépot sur ollama.com n'a finalement que peu de modèles, et la recherche de modèle non-cloud est devenue pénible.

Le gros des modèles est sur huggingface (cocorico!). Personnellement, je suis un peu fâché avec la recherche sur huggingface. Donc j'utilise plutôt un mélange de recherche sur ollama.com puis de recherche Google. Par exemple: huggingface gguf gemma-4 uncensored

Et SillyTavern dans tout ça ?

Pour du role-play, c'est effectivement le seul frontend opensource que je connaisse.
J'ai commencé à jouer un peu avec récemment. Gemma4-31b et Gemma4-26b-a4b m'ont donné des résultats satisfaisant.

Personnellement, je suis un maniaque de l'opensource et de l'hébergement perso, et c'est probablement la question qui m'embête le plus.

Surtout que les développeurs de LLM maintiennent (volontairement ?) une forte confusion entre LLMs opensources et openweights. Les LLMs vraiment opensources sont en fait très rares. Les LLMs openweights sont eux extrêmement nombreux.

Mais même en s'autorisant l'utilisation de LLMs openweights non-opensources, ce n'est pas simple.

En IA, actuellement, tout est surtout question de puissance de calcul. J'ai deux Nvidia RTX 2000 ADA 16go. Mais même avec 32go de VRAM, et je peine à trouver des modèles qui tournent sur mon matériel et qui tiennent la route. Et ironiquement, mes cartes valent 50% plus chères que quand je les avais achetées.

Avec opencode, le seul LLM openweight que j'ai trouvé qui tienne à peu prêt la route en terme de résultats est devstral-small-2:24b-instruct-2512-q8_0 (fait par notre chère boite Mistral, cocorico !). Mais soit j'utilise un petit contexte, et opencode passe son temps à recompacter le contexte (leeennnt), soit le modèle et son contexte débordent de mes cartes graphiques et font travailler le CPU+RAM (leeennnt). Du coup, quoique je fasse, c'est lent.

À ces problèmes, on peut rajouter Nvidia, qui vient d'arrêter le support de ses cartes graphiques Pascal dans ses pilotes. Or, en terme de capacité de calculs, ces cartes sont encore parfaitement utilisables pour de l'inférence (obsolescence programmée ?).

Et dans tous les cas, on est très très loin des résultats actuels d'un Claude Opus 4.6 :-(

De façon générale, le terme "pro" sert juste à facturer plus cher des produits de qualité équivalente, si pas carrément inférieure, au non-pro, non ?

Dans le cas d'un virage complet vers l'extrême-droite, je doute fortement que le porno en lui-même soit vraiment pénalisé/interdit. Mine de rien, ça impacterait une trop large portion de la population. Par contre, il est déjà établi que les minorités sexuelles prendraient cher.

Or ton FAI ne sait pas précisément ce que tu as regardé (merci HTTPS), contrairement au site porno lui-même. Donc à moins d'aller sur jesuisgay.com au lieu de pornhub.com, ton FAI n'aura pas vraiment d'information compromettante sur toi.

Parfois, c'est juste ça ou rien. Surtout dans le monde du logiciel libres où beaucoup de monde est bénévole.

Pour prendre un exemple: mon projet perso est écrit à >90% en Python. Il y a juste deux librairies en C (dont une parce-qu'il s'agit d'algos de traitement d'images, et donc l'écrire en Python aurait été un crime contre l'Humanité). Je n'aurai jamais pu écrire ce projet intégralement en C. Je n'ai juste pas le temps ni la motivation pour ça.

Juste sur les recommandations, certaines ont du sens. Mais d'autres sont juste délirantes.
Je suis notamment fan de la fin de la recommandation 3 :

les sites doivent avoir la charge de déployer des dispositifs techniques conformes à la loi, notamment au RGPD, ce n’est pas aux autorités d’en faire les spécifications.

C'est une belle façon de dire « on a aucune idée de comment faire ça bien, mais démerdez-vous », ainsi que « quoique vous fassiez, vu qu'on a rien spécifié de clair, vous aurez toujours tord ». Je pense que tout ce qui ont déjà eut un dev à faire avec des specs super floues savent de quoi je parle.

J'en suis à la page 26 .. et wow que ce rapport est biaisé. J'ai rarement vu un tel biais dans un document qui se prétend sérieux. Il y a des confusions probablement volontaires, une méconnaissance claire de beaucoup de sujets et de pratiques, et j'en passe. Et surtout, il y a une infantilisation constante de l'adulte moyen, en supposant qu'il/elle n'est pas capable de distinguer fantasme et réalité.

Merci beaucoup ! :-)
J'avais cherché, mais mon Google-Fu s'est révélé insuffisant visiblement.

Hmbon, 216 pages, ça va me faire de la lecture.