Compétences
Python est un langage généraliste dont la lisibilité permet d'exprimer rapidement une règle, mais cette simplicité apparente ne dispense pas de concevoir les structures de données, de répartir les responsabilités et de gérer les erreurs. Je l'utilise principalement dans Odoo, où il porte les modèles ORM, les champs calculés, les contraintes, les actions planifiées, les contrôleurs, les scripts de migration et les tests. Le code s'exécute au sein d'un framework riche : comprendre l'héritage, les décorateurs, les ensembles d'enregistrements et le contexte est aussi important que connaître la syntaxe du langage.
Ma pratique vise un code métier explicite. Je sépare les paramètres des algorithmes, évite les valeurs figées, travaille sur des ensembles d'enregistrements plutôt que sur des hypothèses de volume et tiens compte des transactions et des droits. Lorsque la documentation ne suffit pas, je lis les implémentations standard pour identifier la méthode réellement appelée et reproduire le pattern attendu par la version d'Odoo utilisée.
Je suis également les évolutions du langage, mais je distingue les nouveautés de Python de ce qui est disponible et pertinent dans l'environnement précis de l'ERP. Une fonctionnalité récente n'a de valeur que si elle reste compatible avec le runtime, les conventions et le cycle de migration du produit.
Python 3.14 assure désormais officiellement la prise en charge du mode free-threaded et a notamment ajouté les annotations différées, les template strings et plusieurs interpréteurs dans la bibliothèque standard. Suivre ces évolutions permet de distinguer les nouveautés du langage de ce qui reste compatible avec le cadre précis d'Odoo.
Consulter la source : Python Software FoundationLe module de relance des impayés utilise Python pour sélectionner les factures, calculer leur position par rapport à l'échéance, appliquer les exclusions et déclencher l'action correspondant au palier. Les premières valeurs étaient trop figées. J'ai restructuré le code afin que les délais, modèles de courriel, destinataires, pièces jointes et seuils de blocage proviennent de la configuration. L'algorithme conserve la responsabilité d'appliquer la règle, tandis que les utilisateurs autorisés choisissent les valeurs métier depuis Odoo.
Résultat — Le traitement quotidien couvre automatiquement les factures concernées. Le code peut évoluer sans dupliquer une version du module pour chaque règle de la comptabilité ; le gain de temps reste à mesurer.
Entre Odoo 16 et Odoo 19, des méthodes, modèles, champs et signatures ont changé. J'ai relu les modules internes à chaque version intermédiaire, identifié les appels devenus invalides, recherché les nouvelles implémentations dans le code source et adapté les scripts lorsque des données devaient être transformées. Cette progression 16 vers 17, 17 vers 18 puis 18 vers 19 évitait de cumuler trois causes possibles dans la même erreur et rendait chaque correction attribuable à une évolution précise.
Résultat — Les seize modules utiles ont été conservés sur Odoo 19 et l'ERP a redémarré sans perte définitive de données. Cette migration a renforcé ma capacité à lire du Python écrit par d'autres développeurs et à distinguer une incompatibilité de framework d'une erreur métier locale.
Le calcul de marge et certaines vues comptables m'ont obligé à dépasser le code du module lui-même. J'ai suivi les champs calculés, les dépendances et les appels ORM afin d'identifier ce qui déclenchait des recalculs coûteux. Sur les sujets de sécurité, j'ai vérifié les groupes, ACL et record rules au niveau des modèles et des enregistrements au lieu de me contenter d'un menu masqué. Cette lecture du framework reste prudente : je privilégie une extension contrôlée à une modification directe du moteur standard, qui compliquerait les correctifs officiels et les migrations futures.
Résultat — Les indicateurs de marge sont disponibles pendant l'exercice et les droits restent traités dans les mécanismes prévus par Odoo. La performance doit encore progresser, mais l'optimisation est menée avec des mesures et sans fragiliser le moteur standard.
Les éléments de preuve décrivent des épisodes précis. Cette synthèse les replace dans les études de cas complètes : le contexte, ma contribution et le résultat permettent d'observer ce que cette compétence a rendu possible, avec le niveau de prudence nécessaire sur chaque résultat.
J'estime avoir un niveau intermédiaire. J'utilise Python quotidiennement pour des modules, migrations, API et tâches planifiées, et je peux lire des portions du framework pour diagnostiquer un problème. Mon expérience reste fortement concentrée sur Odoo ; je dois encore approfondir les usages du langage hors ERP, le typage, l'asynchronisme et les outils de profilage plus avancés.
Je conseille de ne pas apprendre Python dans Odoo uniquement par imitation de modules existants. Il faut comprendre les recordsets, les décorateurs et les transactions, puis vérifier les patterns dans le code standard de la version ciblée. Une boucle Python lisible peut rester coûteuse ou incorrecte si elle ignore la manière dont l'ORM charge, calcule et sécurise les enregistrements.
Je poursuis la lecture du code source d'Odoo et de projets Python open source, ainsi que l'étude des évolutions du langage. Le futur service de Business Intelligence doit me donner un contexte complémentaire pour travailler le traitement de données, les API et l'observabilité en Python.
