Le logiciel Autodesk Maya (qu’on abrégera Maya dans le reste du tutoriel) est organisé en couches. On peut en définir trois grosses que je vais vous présenter dans ce chapitre (gardez toujours à l’esprit que la réalité est souvent plus subtile 
).
Le cœur (core en anglais)
Le cœur se compose de trois grosses parties :
- le graphe de dépendance (dependency graph en anglais, souvent abrégé DG) ; dorénavant, j’utiliserais l’abréviation DG ;
- Les commandes ;
- L’interface utilisateur (user interface en anglais, souvent abrégé UI).
Il n’y a aucun moyen de modifier ce code. Ce sont les développeurs de Maya qui le gèrent.
Le graphe de dépendance
On peut voir Maya comme une base de donnée de nœuds (nodes en anglais). Chaque nœud a des propriétés (appelées « attributs » dans Maya) d’entrée et de sortie. Ces attributs sont typés (nombre entier, nombre flottant, chaîne de caractères, énumération, matrice, géométrie, tableau de nombres entiers, tableau de nombres flottants, on y reviendra…). Les types similaires (ou compatibles) peuvent être connectés entre eux, permettant de passer les valeurs des attributs d’un nœud à l’autre. Cet ensemble de nœuds et de connexions forment le graphe de dépendance (dependency graph ou DG).
Chaque type de nœud est responsable d’informer le DG de quels attributs d’entrée dépendent ses attributs de sortie. Cette information permet au DG de garder une trace claire de qui affect qui, de manière à ne recalculer que le strict nécessaire.
Par exemple, vous pouvez avoir un nœud de type nurbsCurve qui a un attribut de sortie contenant une courbe NURBS. Cet attribut peut être connecté à l’attribut d’entrée de courbe d’un nœud de type revolve. Le nœud de type revolve a un attribut d’entrée qui détermine l’angle de la révolution et l’axe de rotation. L’attribut de sortie du nœud de revolve est une surface NURBS. Vous pouvez connecter cet attribut à l’attribut d’entrée d’un nœud de type nurbsSurface qui sait comment dessiner la surface. Vous pouvez ensuite placer le nœud nurbsSurface en enfant d’un nœud de type transform qui sait comment positionner les objets dans l’espace 3D.
La chaîne des nœuds décrite ci-dessus donne ceci :
revolve1) dans le Node Editor de Maya.Les attributs du nœud de type revolve :
Et le résultat dans le viewport Maya :
Comme vous pouvez le constater, si on modifie la courbe ou change la valeur d’un des attributs, cela propage l’information dans tout le graphe qui, un à un, met les nœuds à jour.
Maya fournit de base plus de 600 nœuds. La liste des nœuds est disponible dans la documentation officielle (Technical Documentation/Nodes)
C’est très soviétique me direz-vous mais c’est comme la tête, l’important, c’est ce qu’il y a dedans. 
Et si cela ne suffit pas, vous pouvez créer vos propres types de nœud via l’API (on y reviendra) !
Les commandes
Manipuler directement les nœuds peut être fastidieux. Maya fournit donc plus de 900 commandes qui manipulent le DG pour vous. Ces commandes créent les nœuds, modifient et connectent leurs attributs et créent les nœuds de transformation qui positionnent les objets.
Par exemple, il existe une commande revolve qui prend l’angle et l’axe en argument, et construit le réseau de nœuds présenté précédemment pour la courbe NURBS sélectionnée. Cette commande s’occupe de tous les détails bas niveau pour vous.
La liste des commandes est disponible dans la documentation officielle : MEL Command Reference.
Une fois encore, si vous n’êtes pas content, vous pouvez créer vos propres commandes.
L’interface
C’est tout ce qui fait « tourner » Maya. C’est le code qui détermine dans quel ordre les nœuds vont s’exécuter et comment ces derniers se passent les informations, comment les choses s’affichent dans le viewport, comment s’organise la mémoire quand on ajoute/supprime des nœuds/de la géométrie.
Bref, ce sont les données et leur représentation.
Environ 200 des commandes Maya s’apparentent à la création d’UI et vous permettent de créer vos fenêtres, boutons, icônes, etc. Maya utilise également ces commandes pour sa propre UI. En plus du nœud de type revolve et de la commande revolve existe un menu appelé « Revolve » ainsi qu’une icône « Revolve » dans le shelf. Le menu ou l’icône exécute une commande qui, à son tour, crée le réseau de nœud de DG. Le scripting est utilisé pour implémenter environ 98 % de l’UI de Maya.
Et une fois encore, si vous n’êtes pas content, vous pouvez créer vos propres UI, ajouter des menus, faire vos fenêtres personnalisées (pour les personnages à animer par exemple). 
Vous l’aurez compris, les fondations de Maya sont puissantes et flexibles. Donner la possibilité aux graphistes de pouvoir scripter leurs propres outils et leurs interfaces était révolutionnaire à l’époque où c’était souvent le travail des développeurs. Le fait que n’importe quel TD (technical director/technical artists) puisse écrire des morceaux de script (voir des choses beaucoup plus complexes) pour se simplifier la vie a été déterminant pour la réussite de Maya dans les gros studios.
L'API
L’API (pour Application Programming Interface en anglais et Interface de programmation en français) est la seconde couche. Elle permet de « communiquer » avec le cœur de Maya et de faire pratiquement tout. Tous les nœuds et commandes Maya s’appuient dessus. Elle se compose de centaines d’outils plus ou moins utiles/interconnectés/spécifiques. Elle permet d’aller au plus bas possible pour le plaisir des bidouilleurs (et des crashs à déboguer :P).
Notez que l’utilisation de l’API implique une bonne maîtrise des concepts de programmation.
Il y a, grosso modo, deux gros blocs de classes dans l’API :
- Les classes MPx pour la création de nouveaux types de nœuds (deformer, locator, primitive, etc.) et commandes.
- Les classes MFn pour la manipulation des données.
Puis toutes les autres. 
L’API s’utilise via trois langages de programmation :
- C++
- Python
- .NET
L’API historique est celle en C++. Celle en Python et .NET sont arrivées plus tard et dérivent directement de celle en C++ (comprendre un peu le C++ permet donc de se familiariser rapidement avec l’API).
Vous l’aurez compris, c’est du lourd. 
Le scripting
La dernière grosse couche est celle qui va nous intéresser.
Comme je le disais précédemment, l’API permet de créer des commandes. Mais il faut bien un langage pour les exécuter, ces commandes !
Le MEL
Le MEL (Maya Embedded Langage) est le langage de script historique de Maya.
Une révolution dans l’industrie
À l’époque, beaucoup de logiciels 3D proposaient une API C ou C++ permettant aux développeurs d’augmenter leur logiciel. Bien qu’il s’agisse d’une forme d’ouverture pour les studios, il fallait maîtriser les C/C++ et la compilation pour pouvoir en tirer quelque chose. Ce n’est pas le genre de choses qu’un graphiste sait faire.
Une des spécificités de Maya (et aussi une grosse révolution en son temps) fut de considérer, dès le début du développement du logiciel, l’utilisation d’un langage de script non compilé (ici, le MEL), pour écrire toute la logique « haut niveau » du logiciel : Les menus de l’interface sont écrits et organisés en MEL. Quand vous cliquez sur un bouton/menu, ça exécute du MEL, vous pouvez donc faire tout ce que fait l’interface graphique en MEL.
Bref, du fait de son histoire, le MEL est partout dans Maya.
Cette ouverture, comparée aux autres logiciels, permettait à n’importe quel graphiste n’ayant pas peur de mettre les mains dans le cambouis, d’automatiser une grande partie de son travail. C’est sûrement cette approche qui a permis à Maya de devenir le logiciel de référence dans les grands studios d’animation et d’effets spéciaux.
Aperçu
Comme nous ne parlerons plus du MEL car tout ce tutoriel se focalise sur Python, voici un très bref aperçu.
Le MEL est un langage fonctionnel. Un langage fonctionnel est une manière d’organiser et d’écrire du code. Pour vous donner un exemple, la forme résultat = action(données) est typiquement une écriture en langage fonctionnel. En MEL on peut ne pas mettre les parenthèses. Ainsi, l’exemple précédant donnerait résultat = \action données``.
Tout est global en MEL. Si vous déclarez une fonction qui porte le même nom qu’une fonction utilisée par Maya, vous pouvez casser Maya. Exemple :
polyPerformAction est une fonction utilisée un peu partout dans l’interface :
whatIs polyPerformAction
La commande MEL whatIs donne des informations sur une commande donnée.
// Result: Mel procedure found in: (votre installation)/scripts/others/polyPerformAction.mel //
On voit ici que la fonction polyPerformAction est définie dans un fichier en .mel dans le dossier d’installation de Maya.
Comme vous l’aurez remarqué dans la valeur de retour de whatIs, en MEL, on ne parle pas de « fonction » mais de « procédure ». Mais c’est un détail. Ne vous embêtez pas avec ça, nous allons nous contenter du terme « fonction ». 
Si on essaye de la redéfinir (c.-à-d. créer une nouvelle commande qui porte le même nom que la fonction à redéfinir) :
global proc polyPerformAction()
{
print("TEST");
};
Maya nous met en garde :
// Warning: New procedure definition for "polyPerformAction" has a different argument list and/or return type. //
Mais on a cassé Maya. Si, par hasard, on fait quelque chose dans l’interface qui appelle la commande polyPerformAction, il y a de fortes chance qui votre Maya vous affiche des messages d’erreur. Heureusement, il suffit de redémarrer le logiciel pour repartir de zéro.
Une bonne pratique des studios (et d’une manière générale) était de préfixer leurs fonctions avec un diminutif du studio.
Le déclin
Au fil des années deux problèmes majeurs apparurent :
- Le MEL commençait à accuser son âge et sa rigidité est devenu problématique alors que d’autres langages (dits à typage dynamique) commençaient à percer.
- Le MEL étant fermé et limité à Maya, aucune interopérabilité avec d’autres outils n’était possible. Il fallait donc obligatoirement passer par du C++.
Une alternative était nécessaire…
Python à la rescousse !
En 2007, Maya 8.5 embarque un interpréteur Python (version 2.4.3) permettant d’exécuter des commandes de script, mais surtout également, des commandes de l’API C++. C’est une avancée majeure pour les studios de production car Python n’est pas juste un langage de script mais un écosystème de modules intégrés (Python est dit battery included) et tiers, là où le MEL est vraiment seul et (quasi) vide.
Cet ajout a eu une portée quasi historique dans l’histoire de la fabrication des effets spéciaux, car le mouvement a été suivi par tous les autres logiciels du marché.
À l’heure actuelle, Python est le langage de prédilection des pipelines des studios d’effets spéciaux.
Note concernant la version de Python
L’industrie des effets spéciaux est assez paradoxale. D’un côté elle est à la pointe des technologies concernant la représentation et la manipulation artistique de données monstrueuses et complexes (scène, rendu, géométrie, animation, etc.) mais est totalement à la ramasse sur les bibliothèques, chaque logiciel utilisant la version qu’il jugeait la plus pertinente. 
Il faut garder à l’esprit que la programmation et le code n’est qu’une partie assez secondaire du travail lié à l’image. La priorité des développeurs des logiciels est mise sur la capacité itérer rapidement sur la qualité d’une image.
La situation est devenue telle que différents développeurs de logiciels concurrents ont décidés de s’organiser pour « synchroniser », avec plus ou moins de succès, les différentes versions des bibliothèques utilisées au fil des années. Cet effort a donné naissance à la VFX Reference Platform dont je vous traduis la phrase d’introduction :
La Plateforme de Référence VFX est un ensemble de versions d’outils et de bibliothèques communs sur lesquels s’appuyer pour concevoir des logiciels pour l’industrie des effets spéciaux. Son but est d’atténuer les incompatibilités entre les différents logiciels, faciliter la maintenance des pipelines de production utilisant Linux et d’encourager l’adoption de Linux par les éditeurs de logiciels. La Plateforme de Référence est mise à jour annuellement par un groupe d’éditeur de logiciels en collaboration avec le Visual Effects Society Technology Committee.
Ainsi, Python a été intégré pour remplacer le MEL qui devenait était déjà vraiment vieillot et faisait perdre du temps aux équipes. La version a évolué au fil des années de 2.4 à 2.7. Sauf que la version 3 n’était pas rétrocompatible. Ainsi, du code écrit en 2.7 n’était pas directement compatible avec Python 3. Ceci, ajouté au fait que :
- à l’époque Python 3 n’apportait rien de vraiment révolutionnaire par rapport à 2.7,
- certaines librairies ne fonctionnent pas en Python 3 (PySide 2 + Qt 5.6),
- des pipelines entiers ont été montés en Python 2.7,
- le script n’est pas une priorité pour les éditeurs de logiciels,
fait que le passage à Python 3 n’est pas prévu avant 2020, date de fin de support de la branche 2.7 par la communauté Python, qui ne corrigera plus les failles de sécurité.
Comprenez que ce n’est pas pour tout de suite et ça va être un joyeux bordel le jour où ça arrivera !
Tous les codes que vous verrez seront donc en 2.7.
Nous venons d’avoir un aperçu général du fonctionnement de Maya et quelles ouvertures il laisse à ses utilisateurs suivant le langage qu’ils utilisent. C’est sûrement encore un peu abstrait, mais gardez à l’esprit que nous n’utiliserons que Python.