Je relance mon compte X.
J'ai compris que prendre la parole n'est plus une option et surtout que ça permet de partager, inspirer, apprendre et comprendre. Sur les autres et surtout sur soi même.
Je suis entrepreneur, j'ai créé, fermé, repris, revendu plusieurs entreprises.
L’UE vient de classer ChatGPT comme « très grand moteur de recherche » au titre du DSA.
Donc après l’AI Act, OpenAI devra aussi se taper 4 mois de conformité supplémentaire : obligations, audits, reporting, procédures.
On régule l’IA avec l’AI Act.
On régule maintenant ChatGPT comme un moteur de recherche avec le DSA.
Toujours plus de couches. Toujours plus de régulations.
Et on se demande pourquoi on fait du sur place en Europe 🤦🏼♂️
500 abonnés !
Il y a encore du chemin à parcourir, publier avec peu de visibilité et interactions franchement ça demande du mental hein !
Je vais continuer à développer le compte 🤘🏻
@AubinThomas Force à toi. Amazon est une des pires entreprises avec qui travailler, les comissions sont minables (et ça va encore drop), ils ont des règles de plus en plus strictes pour les comptes partnaires
Exemple d'un des modules Odoo : Un fournisseur nous envoyait son catalogue en CSV. Il a ouvert une API. Il fallait migrer sans casser un import qui tourne tous les jours en prod.
Le code d'origine faisait tout d'un bloc : télécharger, parser, écrire. Je l'ai coupé en deux avant de toucher à quoi que ce soit :
lire le fichier() ─┐
├─→ appliquer (données)
lire l'api() ───┘
Toute la logique métier, comparaison, mise à jour, garde-fous, vit dans appliquer. Les deux sources ne font que produire la même structure de données.
Au final la migration a été un paramètre. Un réglage dit quelle source utiliser, l'ancienne reste disponible en repli, et le comportement métier est identique par construction puisque c'est le même code.
Avant de remplacer une source de données, isolez ce qui ne dépend pas de la source et ensuite migrez en connaissance de cause.
Pendant des années, c'est le CMS boutique qui facturait. Il fallait passer à l'ERP. Une seule contrainte : jamais deux factures pour une vente, jamais zéro.
Mon premier réflexe c'était de marquer toutes les commandes existantes comme « déjà facturées » mais c'était mauvais : le champ qui porte cette information est calculé, donc non fiable à l'écriture.
La solution qui tient c'est une date pivot stockée en paramètre, lue par les deux systèmes. Avant cette date, l'ancien facture. À partir de cette date, l'ERP. Un seul point de vérité, partagé.
Doublé d'un killswitch : le module s'installe inerte, on le déploie tranquillement, on bascule quand on veut. Et repasser le switch à zéro met en pause et ça ne rend pas la main à l'ancien système, ca évite la fausse manœuvre.
Un angle mort trouvé à la relecture : la boutique continuait à demander une facture au moment de l'expédition. Sans garde de son côté aussi, la double facture était garantie.
Odoo permet un champ calculé et stocké en base : pratique, on peut filtrer et trier dessus mais c'est aussi un piège : quand vous changez la formule et redéployez, Odoo ne recalcule rien. Les anciennes valeurs restent, silencieusement fausses. Aucune erreur.
Je l'ai vécu sur le projet : une règle de périmètre corrigée à un endroit. Résultat, une douzaine de commandes exclues des préparations du lendemain, sans le moindre message. Il faut un script de migration explicite qui force le recalcul.
Nuance importante qu'on a vérifiée : pour un champ nouveau, Odoo remplit bien l'existant tout seul. La règle ne vise que les formules qui changent.
Le test qui permet de vérifier est de supprimer la colonne en base, relancer la mise à jour, regarder si elle se remplit. Ça reproduit exactement la première installation.
Un produit physique qui est compatible avec des centaines d'appareils différents. Des dizaines de milliers de fiches à gérer. Le réflexe Odoo, c'est les variantes mais je ne les ai pas utilisées.
Une variante partage le stock avec son modèle parent et hérite de sa structure. Or ici, chaque « compatibilité » a son propre titre, sa description, son code-barres, sa fiche sur les places de marché, mais aucun stock propre. Ce n'est pas une déclinaison d'un produit, c'est une porte d'entrée vers lui.
Choix retenu : deux niveaux de produits reliés par une simple relation, plus une poignée de champs recopiés du parent vers ses compatibilités par calcul.
Ça a l'air moins propre que les variantes. En pratique, ça a évité une réécriture complète le jour où il a fallu que chaque compatibilité porte son propre identifiant commercial chose qu'une variante ne sait pas faire proprement.
Leçon : le mécanisme natif qui ressemble le plus à votre besoin n'est pas toujours celui qu'il vous faut. Regardez ce qu'il impose, pas ce qu'il permet.
Notre Odoo custom e-commerce tient en 10 modules maison plutôt qu'un seul gros. Ça paraît sur-découpé pour une petite structure mais c'est justement plus intelligent.
Le graphe est linéaire et suit le flux physique :
catalog → stock → sync → orders → purchase → picking → shipping → dispatch → invoicing
Chaque module ne dépend que de ce dont il a réellement besoin. shipping dépend de orders et du stock natif. invoicing dépend de dispatch parce qu'on ne facture qu'après expédition, et cette règle métier est inscrite dans le graphe de dépendances, pas dans un com.
Le bon point : je peux mettre à jour un module en prod sans toucher aux autres. Un correctif de préparation de commandes ne dedéploie pas le moteur de factu.
Le coût : il faut réfléchir avant de poser une fonction. Un helper mal placé crée une dépendance circulaire, et Odoo refuse de démarrer, après c'est une contrainte utile puisqu'elle oblige à répondre à « à qui appartient la règle ? » au lieu de la coller là où c'est pratique.
Ce qui a été construit sur Odoo : Un ERP complet, en dix briques qui s'enchaînent :
Le référentiel : un produit physique est compatible avec des centaines d'appareils. Modéliser ce 1-vers-N proprement, à l'échelle de dizaines de milliers de fiches, conditionnait tout le reste.
Le stock : import quotidien du catalogue fournisseur, d'abord par fichier, puis migré vers son API. Disponibilité et délais recalculés en continu.
La boutique : synchronisation automatique du stock, des délais et des prix vers le site, qui alimente lui-même les marketplaces.
Les commandes : import horaire, avec détection des annulations et régime fiscal déduit automatiquement du pays du client.
La préparation : vagues quotidiennes, feuille de picking, cinq boutons par transporteur, étiquettes générées ou imprimées selon le cas.
Les transporteurs : routage automatique selon destination, poids et service, étiquettes en API, suivi renvoyé au client.
Les achats : consolidation quotidienne des besoins en une commande fournisseur, puis réception au quai avec allocation aux commandes.
La facturation : bascule complète : c'est l'ERP qui facture désormais, avec la TVA du pays de destination et les régimes européens.
Autour : SAV structuré, monitoring, sauvegardes testées par restauration réelle, envoi des factures par e-mail, manuel opérateur illustré généré en PDF.
J'attaque ma série sur l'intégration d'un nouvel ERP suite à reprise d'entreprise ->
Un e-commerce revendeur, vendant sur son site et une dizaine de places de marketplaces.
Toute la logistique tenait sur des exports manuels, des fichiers Excel et le back-office de la boutique.
Pas d'ERP, pas de stock fiable, pas de compta outillée.