Blender sur GitHub
un miroir officiel, pas le vrai dépôt
Le code y est authentique, mais le développement se passe ailleurs. Et les add-ons, eux, vivent bien sur GitHub.
Le dépôt Blender visible sur GitHub est un miroir officiel en lecture seule : le code y est copié depuis projects.blender.org, la forge que le projet héberge lui-même et où se déroulent le développement, la revue de code et le suivi des bugs. Les add-ons de la communauté, en revanche, sont bel et bien publiés sur GitHub, et se récupèrent dans la section Releases du dépôt, jamais via le bouton vert de téléchargement du code.
- Miroir en lecture seule : le code descend de la forge du projet, rien ne remonte.
- Bugs et contributions : sur projects.blender.org, pas dans les issues du miroir.
- Les add-ons, si : l’écosystème d’extensions est massivement hébergé sur GitHub.
- L’erreur classique : télécharger le code brut au lieu de l’archive publiée en Releases.
Sur GitHub, Blender n’est qu’un reflet
Cherchez Blender sur GitHub et vous tombez sur un dépôt qui porte le bon nom, affiche une activité soutenue et ressemble en tout point au dépôt officiel du projet. Il l’est, en partie seulement : la page se présente elle-même comme un miroir officiel, synchronisé depuis projects.blender.org, la forge que la Blender Foundation héberge de son côté.
La nuance n’est pas cosmétique. Un miroir est une copie qui se met à jour dans un seul sens. Le code y arrive, il n’en repart pas. Une pull request ouverte depuis cette page, un ticket déposé dans les issues du miroir : ni l’un ni l’autre n’atteindront l’équipe, le README du dépôt renvoyant explicitement la revue de code et le signalement des anomalies vers la forge du projet.
C’est la source d’une bonne partie des malentendus autour de cette recherche. Des utilisateurs découvrent le dépôt, tirent la conclusion logique que tout se passe là, et écrivent au mauvais endroit.
Où se passe réellement le développement
Le projet fait tourner sa propre forge logicielle sur projects.blender.org, publiquement accessible, avec le dépôt principal, le suivi des tickets et la revue des contributions. C’est là que les développeurs proposent leurs modifications, que les rapports de bugs sont triés et que les discussions techniques laissent des traces consultables.
Le choix se comprend pour un logiciel libre : dépendre d’une plateforme commerciale pour l’infrastructure d’un projet communautaire revient à confier à un tiers les règles, la disponibilité et l’historique du code. L’auto-hébergement coûte du temps d’administration, mais il garde cette maîtrise.
Le miroir
Copie officielle et à jour du code. Consultation, recherche dans les sources, historique des commits, fork personnel. Aucune contribution ni aucun ticket n’y sont traités.
La forge du projet
Dépôt de référence, suivi des bugs, revue de code, discussions techniques. C’est l’adresse à retenir dès qu’on veut signaler quelque chose ou contribuer.
À quoi sert quand même le miroir GitHub
Il reste utile, et pas seulement par confort. Chercher une fonction ou une chaîne de caractères dans l’ensemble des sources y est agréable, l’outil de recherche de la plateforme se montrant efficace sur les gros dépôts. Consulter l’historique d’un fichier, comprendre quand une fonctionnalité est apparue, retrouver le commit derrière un changement de comportement : tout cela se fait très bien depuis le miroir.
Il sert aussi à garder une copie personnelle. Un développeur qui veut expérimenter sur sa propre version, sans intention de reverser ses modifications au projet, travaille depuis là sans difficulté.
Le miroir affiche un avertissement sur les erreurs liées au stockage des gros fichiers, susceptibles de survenir lors du clonage. Ce n’est pas un défaut du projet mais une conséquence de la synchronisation entre deux plateformes. La documentation développeur du projet donne la marche à suivre à jour.
Les add-ons, eux, vivent bien sur GitHub
C’est souvent la vraie raison d’arriver sur cette recherche. Blender se prolonge par des extensions écrites par des tiers, et cet écosystème est massivement publié sur GitHub. Un développeur indépendant qui écrit un outil de modélisation, un exportateur de format ou un utilitaire de rendu le dépose là, sans lien organique avec le projet principal.
La différence de statut compte. Le code de Blender passe par une revue collective avant d’être intégré. Un add-on tiers n’est validé par personne : c’est du code écrit par un inconnu, qui s’exécutera avec les mêmes droits que le reste de votre session. Rien d’alarmant en soi, la grande majorité de ces projets étant sérieuse et transparente, mais cela justifie deux minutes d’attention.
Le rythme de maintenance varie aussi énormément. Certaines extensions suivent chaque version majeure du logiciel, d’autres sont abandonnées après quelques mois et cessent de fonctionner à la première évolution de l’interface de programmation.
Récupérer un add-on sans se tromper de fichier
C’est ici que les utilisateurs se trompent le plus souvent, et l’erreur est toujours la même : le bouton vert Code fournit une archive du contenu brut du dépôt, avec les fichiers de développement, la documentation et parfois les tests. Ce n’est pas ce que Blender attend à l’installation.
-
Ouvrir la section Releases
Dans la colonne de droite de la page du dépôt, la section Releases liste les versions publiées. Le développeur y dépose l’archive prête à installer, généralement accompagnée d’une note de version.
-
Vérifier trois choses avant de télécharger
La note de version doit couvrir votre version de Blender, une extension écrite pour une version ancienne pouvant refuser de s’activer. La date de la dernière publication renseigne sur la maintenance. Et le fichier doit être une archive, jamais un exécutable.
-
Installer depuis les préférences
Dans Blender, les préférences permettent de pointer l’archive récupérée, puis d’activer l’extension en cochant sa ligne dans la liste. Si le dépôt ne publie aucune release, son fichier de documentation indique en général quel dossier copier manuellement : suivre ses instructions plutôt qu’improviser.
Repérer un dépôt douteux
Quelques signaux se lisent en trente secondes. Un dépôt actif montre des modifications récentes, des issues ouvertes et refermées, parfois plusieurs contributeurs. Un dépôt sans activité depuis longtemps n’est pas dangereux en soi, mais il y a de fortes chances qu’il ne fonctionne plus avec les versions actuelles.
La présence d’une licence explicite est un bon indicateur de sérieux, tout comme une documentation minimale expliquant ce que fait l’extension et comment l’installer. Un projet qui ne dit rien de son fonctionnement mérite la même méfiance qu’un logiciel téléchargé au hasard.
Blender ne se télécharge pas sous forme d’exécutable proposé par un dépôt tiers. Tout ce qui ressemble à un installeur du logiciel hébergé ailleurs que sur le site officiel du projet doit être tenu pour suspect, quelle que soit la ressemblance du nom, du logo ou de l’adresse. Les projets libres populaires sont des cibles régulières pour ce type d’imitation.
Reste la question que beaucoup d’utilisateurs se posent en découvrant tout cet appareillage : non, aucun compte GitHub n’est nécessaire pour installer et utiliser Blender. On peut modéliser, animer et faire des rendus sans jamais ouvrir la moindre page de dépôt.
Le dépôt Blender sur GitHub est-il officiel ?
Oui, mais c’est un miroir. La page se décrit elle-même comme un miroir officiel, synchronisé depuis la forge auto-hébergée du projet. Le code qu’on y trouve est donc authentique, mais la copie ne fonctionne que dans un sens : rien de ce qui est déposé sur le miroir ne remonte vers le projet.
Où signaler un bug ou proposer un correctif ?
Sur projects.blender.org, pas sur le miroir. Le README du dépôt GitHub renvoie explicitement la revue de code et le suivi des anomalies vers cette adresse. Un ticket ouvert dans les issues du miroir a toutes les chances de rester sans réponse.
Faut-il un compte GitHub pour utiliser Blender ?
Non, à aucun moment. Le logiciel se télécharge depuis le site officiel du projet et s’utilise sans aucun compte. Les dépôts de code concernent les développeurs et les utilisateurs qui installent des extensions tierces, pas l’usage courant.
Comment installer un add-on trouvé sur GitHub ?
En passant par la section Releases du dépôt, où le développeur dépose une archive prête à installer, plutôt que par le bouton vert de téléchargement du code, qui fournit le contenu brut du dépôt. L’archive s’installe ensuite depuis les préférences de Blender, puis l’extension se coche dans la liste.
Comment savoir si une extension est compatible avec ma version ?
La note de version publiée par le développeur indique généralement les versions prises en charge. À défaut, la date de la dernière publication donne une indication : une extension sans mise à jour depuis plusieurs versions majeures a de bonnes chances de ne plus s’activer.
Retenir deux adresses suffit : le miroir pour lire le code, la forge du projet pour tout le reste. Le reste du temps, Blender s’utilise très bien sans jamais y mettre les pieds.