Jérôme Flesch a écrit 359 commentaires

Ç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.

Le problème avec le contrôle d'accès en aval, c'est que invariablement, il va obliger les utilisateurs à s'exposer plus.

Prenons un exemple:

• le contrôle de l'âge par la carte bancaire
• une personne homosexuelle (ou bi, ou autre, on s'en fout, c'est pour l'exemple)
• et les tendances politiques des dernières décennies (montée notable et continue de l'extrême-droite).

Ça veut dire cette personne va devoir donner un élément permettant de l'identifier clairement et durablement (le numéro de carte bancaire ; même un numéro temporaire est traçable) et de l'associer à ses pratiques personnelles. Avec la montée de l'extrême-droite, je peux comprendre que ce genre de personne ne veulent pas de ces moyens de contrôle.

Par contre, je pense qu'il serait possible de contrôler ça autrement et plus intelligemment : Par exemple, on pourrait obliger les FAI à fournir une solution de contrôle parentale, soit intégrée à la box, soit en amont. Solution de contrôle qui devrait être activée par défaut (à cause des incultes de la technologie) et qui devrait pouvoir être désactivée en quelques clics par l'abonné.

Mais je soupçonne que ce n'est pas ce que vise ni ce communiqué, ni le rapport du HCE.

J'allais te faire une réponse du genre quand je viens de voir passer cet article de libé

Je pense que l'article de Libé fait référence au même rapport HCE que ce thread Twitter mentionné ici dans un commentaire plus bas: https://nitter.net/MelanieJaoul/status/1706765288664961527

Faute d'accès direct au rapport, je ne peux que me baser sur les articles de journaux qui en parlent genre Libé et Figaro ainsi que sur ce thread Twitter. De ce que j'en vois, on peut difficilement faire plus biaisé que ce rapport. Le thread Twitter y répond très bien. À noter que la page de garde du rapport seule donne tout de suite le biais. Ici, Libé a visiblement repris le rapport sans aucun esprit critique (c'est plus sensationnaliste je suppose).

Commençons par le forme :

Ce que j'aime avec les mots valises, c'est que ça permet d'associer deux idées qui ne sont pas forcément liées au départ, et donner l'impression qu'elles sont toujours allées de paire. « Criminalité pornographique » ou « pornos criminels », ça ne donnait pas assez l'impression que c'est complètement ordinaire et forcément lié. On avait « cybercriminalité », maintenant on a « pornocriminalité ».

De plus, le communiqué associe immédiatement violence et criminalité. À aucun moment les deux ne sont distingués. À aucun moment, je n'ai vu le mot « consentement ». Si on suit cette logique, est-ce qu'il faudrait interdire la boxe ? oO

Maintenant sur le fond :

Concernant la production, de mon point de vue, la seule vraie question est: est-ce que les actrices ont clairement été informées et sont consentantes ? Tout le reste n'est que du puritanisme mal placé, qui ne fera qu'empirer la situation en cachant la merde sous le tapis. Pour référence, je vous renvoi à la Prohibition.

Concernant l'accès, le contrôle de la majorité a toujours été un problème. La seule méthode à peu prêt fiable que je connaisse serait de demander un numéro de carte bancaire. Sauf que je présume que la plupart des gens préfèrent consulter leurs pornos plutôt anonymement (pour des raisons assez variées et assez évidentes je pense). Or ça ne va pas dans ce sens. En fait, je pense qu'aucune méthode de contrôle ne peut aller dans ce sens. Bref, pas si simple.

Concernant le contrôle de la diffusion, pour ma part, je n'ai eut à faire à un site pornographique qu'une fois. Une amie m'avait contactée paniquée parce-qu'un de ses ex avait posté un revenge porn sur Pornhub. J'ai fait la demande de suppression en son nom, et la vidéo a été retirée dans la journée. Si ils font toujours preuve de cette réactivité, je ne suis pas sûr de voir ce qu'on attend plus d'eux ?

• Avoir des humains qui filtrent en amont les vidéos ? On leur reprochera ensuite de causer des traumastismes psychologiques massifs à des sous-traitants.
• Pré-filtrer avec de l'IA ? Pour les entraîner, il faut des datasets massifs de vidéos de référence qui seraient par définition illégales …

Bref, pas si simple.

Apparemment, c'est « Piccard » avec deux « c ». Quelqu'un peut-il corriger le titre et la 2ième phrase du journal s'il vous plaît ?

edit: bon ben j'ai été trop lent :)

"Charge", j'ai l'impression que c'est du niveau d'un jeu vidéo sur carte graphique puissante moderne que tout le monde (aisé) peut avoir à la maison pour faire le rendu en temps réel.

Si tu regardes le making of de Charge, ça s'explique très bien. Ils voulaient justement tester le rendu temps-réel.

De plus, je soupçonne que tu regardes les mauvaises choses : sauf erreur de ma part, le but des courts-métrages de Blender est avant tout de tester et améliorer les dernières fonctionnalités en conditions réelles. Il ne s'agit pas de faire des démos impressionnantes de A à Z. Tout au plus, il s'agit de montrer que Blender peut très bien faire certaines choses bien précises. Il ne faut pas non plus oublier qu'en même temps qu'ils font ces courts-métrages, ils développent Blender en parallèle, le tout avec une petite équipe pour un tel logiciel. Du coup, ils n'ont sûrement pas le temps de peaufiner dans les moindres détails les éléments des courts-métrages qui ne sont pas leur priorité.

Par exemple, dans Charge, si tu regardes le making of, il me semble clair que leur focus état surtout sur le visage photoréaliste et son animation. Et pour le coup, je trouve le visage et l'animation du personnage impeccable. Par contre, c'est sûr que si tu regardes l'usine et les robots autour de lui …

Pour les autres, je n'ai pas encore regardé les making of, mais je devine qu'ils testaient :
* dans Tears of Steel, le mix réalité/CGI, clairement ;
* dans Sprite Fright, ils testaient le dessin animé 3D cartoon ;
* dans Spring, les effets de lumière et de gaz ;
* etc.

Si tu veux du photoréaliste impressionnant avec Blender, je te recommande plutôt de regarder du coté de Ian Hubert (et même là, il faut garder à l'esprit qu'il fait ça grosso-modo tout seul à ma connaissance).

Il y a aussi quelques gros noms qui utilisent et parrainent Blender aussi mine de rien. Par exemple:

• Google
• Microsoft
• Ubisoft
• Adobe