Odoo, l’éditeur de logiciels libres de gestion, vient de lancer Scale‐Up!, un jeu éducatif pour apprendre la gestion d’entreprise. Dans ce jeu de cartes, vous incarnez un entrepreneur qui doit développer son entreprise grâce à sept cas de gestion : achat et vente, lancement d’un magasin, fabrication des produits, lancement d’une boutique en ligne, etc. Le jeu est offert gratuitement à tous les professeurs, ainsi qu’à leurs étudiants (et vendu 28 € HT sinon).
Scale-Up! prend la forme d’un jeu de cartes comprenant sept scénarios business, mixé avec l’utilisation en ligne d’Odoo pour mettre en pratique l’organisation de l’entreprise. Ce jeu peut être utilisé par des étudiants qui souhaitent apprendre le fonctionnement d’une entreprise, ou par des entreprises qui souhaitent découvrir Odoo en profondeur.
Le recto de chaque carte décrit un contexte business : négociation avec un fournisseur, création d’une fiche produit, analyse des résultats, etc. Le joueur doit ensuite mettre en place la solution pour gérer ce problème dans Odoo, et vérifier sa solution avec le verso de la carte afin de voir combien de points il gagne.
Le jeu est actuellement en anglais, mais une version française est prévue pour septembre (limitée à quatre cas sur les sept). Elle sera également offerte gratuitement à tous les professeurs et leurs élèves.
En parallèle, Odoo vient également d’annoncer que la version 13 (disponible en octobre) contiendra une nouvelle application libre pour gérer les cours en ligne de manière ludique : gestion des supports de cours, forums de discussions, gestion des certifications, etc. Vous pouvez déjà tester cette application sur les cours en ligne d’Odoo.
Aller plus loin
- Scale‐Up!, le business game (226 clics)
- Odoo, le site officiel (258 clics)
- Revue du jeu en français (233 clics)
# coquille
Posté par audionuma (site web personnel, Mastodon) . Évalué à 3.
Manque un 'o' dans l'url des cours en ligne.
[^] # Re: coquille
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 2.
Corrigé, merci. En fait il y avait le nombre de « o » requis mais pas au bon endroit.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
# Pas réaliste
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
La gestion d'entreprises réelles n'a rien avoir avec ce qui est présenté dans le jeu.
Un entrepreneur moderne n'est pas celui qui mets en place les achats/ventes, lance un magasin ou fabrique des produits.
Il faudrait au minimum reprendre les grandes étapes suivantes de tout bon gestionnaire de la startup nation:
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas réaliste
Posté par Kerro . Évalué à 1.
Ce que tu décris là correspond probablement à moins de 1 % des entreprises.
Donc ton exemple n'a lui aussi que peu à voir avec la vraie vie.
[^] # Re: Pas réaliste
Posté par pinky . Évalué à 10.
Je suis parti pris car je suis co-auteur du jeu. Je suis également fondateur et CEO d'une société de 660 employés (Odoo).
Je pense au contraire que Scale-up!, représente bien les challenges d'un entrepreneur moderne. Le jeu ne couvre pas les aspects stratégiques de la gestion d'entreprise, mais plus les aspects d'execution. (Et un entrepreneur passe la majorité de son temps dans l'exécution, très peu dans les reflections stratégiques)
Scale-up! ne couvre évidemment pas toutes les fonctions d'un entrepreneur, mais les processus proposés couvrent quand même de nombreux besoins: achats, ventes, gestions de projets et services, organisation d'un entrepôt avec barcodes, fabrication, lancement d'une boutique en ligne, création d'une app sur mesure.
Nous aidons des centaines d'entreprises a améliorer leur gestion. Et, très souvent, cela passe par mettre en place des processus efficaces. C'est clé pour faciliter la croissance.
[^] # Re: Pas réaliste
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 10.
Il me semble que le commentaire de devnewton soit à prendre au second degré ; une sorte de dénonciation d'une certaine sorte d'entrepreneuriat anti-productif, plutôt que son apologétique et la condamnation d'un travail réel que semble présenter votre jeu.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Pas réaliste
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
Dans ce cas, il ne faut pas appeler le jeu Scale-up!, mais Stay-Little! :-)
Ou alors la stratégie c'est pour une extension à venir?
Rentabiliser un jeu par la vente de DLC, c'est en soit une stratégie!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas réaliste
Posté par Elfir3 . Évalué à 6.
J'propose d'en faire une version pour enfant et utiliser un insecte sur la boite du jeu, une fourmi par exemple.
[^] # Re: Pas réaliste
Posté par _alex . Évalué à 3.
Parfois la réalité taquine la caricature et le sarcasme bien plus qu'on le croit…
# odoo est-il encore libre ?
Posté par tuxrouge . Évalué à 4.
C'est une question un peu naïve mais j'avais cru comprendre que la version CE était amputée de fonctionnalités à chaque nouvelle version. Je me trompe ?
concernant le jeu je serai curieux de le tester avec mes jeunes et d'en mesurer l'efficience
[^] # Re: odoo est-il encore libre ?
Posté par fatypunk . Évalué à 4.
Non ce n’est pas faux mais en fait autant basculer vers les modules fonctionnels de la communauté (OCA) et/ou développer ce dont tu as besoin par dessus car les fonctionnalités de base ne vont pas très loin et s’avèrent vite insuffisantes.
Le framework est plutôt bon par contre. Évidement il y a des choix que l’on peut contester mais ils s’expliquent et le ratio simplicité du truc/facilité d’usage est très agréable. Le gros point noir est l’utilisation des float python pour le stockage des montant alors que dans une appli de gestion on utilise toujours des décimaux. La virgule flottante pour des montants c’est une horreur ! C’est un truc qui bouffe énormément d’énergie avec des erreurs récurrentes au centime. Et j’ai constaté que tout le monde réinvente ses solutions pour palier au problème.
[^] # Re: odoo est-il encore libre ?
Posté par pinky . Évalué à 8. Dernière modification le 22 juillet 2019 à 17:18.
Je serais intéressé d'avoir un feedback sur vont besoins qui n'ont pas été couverts par le standard. Pouvez-vous m'envoyer une liste par email (fp AT odoo DOT com)? On va justement définir notre roadmap v14, dans qq semaines.
Voici l'explication de notre choix pour l'implémentation des floats: Odoo gère bien les chiffres comme des decimal au niveau de PostgreSQL (numeric), mais comme des floats en mémoire (ORM). C'est pour moi le meilleur compromis car:
- tout est bien stocké en decimal après chaque opération dans la DB (tronqué correctement en fonction de la devise / UoM / …). C'est pratique car un champ a bien un contexte défini (précision, rounding), alors que les variables intermédiaires dans le code n'en ont pas nécessairement.
- cela ne pose strictement aucun problème d'arrondi pour des use cases business (les float Python sont des double C --> 11 bits exposant, 52 bits valeur), le seul risque est de ne pas faire une comparaison correcte à 0, lorque vous développez un module custo.
Utiliser le type decimal en Python serait en fait beaucoup plus compliqué, principalement à cause des getcontext() -> on ne ferait que déplacer le problème (comparaison à 0) à toutes les opérations arythmétique (mise en place du bon contexte à chaque calcul, au lieu de s'appuyer sur la définition du champ lorsque l'on stocke la valeur).
Par exemple, lorsque vous faites: Prix TTC = Pric HTVA * Quantité * Discount * TVA, chacune des variables ont des précisions différentes, il faudrait alors démultiplier les appels à decimal.getcontext().prec = X. Calculer en float, et tronquer à la fin (lorsque la variable Prix TTC est ensuite écrite dans le champ amount_total pour qui une précision est définie) est à la fois plus performant, et beaucoup plus simple. On considère le risque d'erreur négligeable car il faut un montant à 1016 chiffres pour avoir un risque de un cent. (ce que probablement aucune société au monde n'a dans ses comptes, sur un seul document)
Le risque de bug par un développeur de module est pour moi beaucoup plus grand si Odoo n'utilisait que des decimals, au lieu de cette approche mixte (à cause des multiples définitions de contexte, alors qu'ici c'est délégué à la définition du champ de l'objet). Sans compter les multiples exceptions TypeError lorsque l'on multiplie un vrai float (discount/quantity) par un decimal.
[^] # Re: float vs decimal
Posté par Cédric Krier (site web personnel, Mastodon) . Évalué à 4.
Ça n'a pas l'air d'être vraiment le cas: https://odoo-community.org/groups/contributors-15/contributors-136015
Ce n'est pas limité à seulement la comparaison à 0 mais à n'importe quelle chiffre et opérateur (>, <, >=, <=).
En fait, le contexte de decimal ne doit pas être mis à jour pour chaque variable. Dans le pratique on définit une fois la précision des calcules intermédiaires (les valeurs par défaut
prec=28, Emin=-999999, Emax=999999sont bien dans la majorité des cas). Et on arrondit le résultat final à la précision attendue.Ça dépend ce qu'on appel un bug. Si ne pas avoir d'exception mais un résultat incorrect n'est pas un bug alors oui. Mais à mon avis, il est préférable de détecter les bug en levant une exception mais si le résultat pour le cas courant n'est pas faux.
En fait utiliser des Decimal permet d'avoir un vrai test sur la précision du nombre stocker dans un champs et donc d'éviter la découverte trop tard de problème d’arrondi comme https://odoo-community.org/groups/contributors-15/contributors-136015
[^] # Re: float vs decimal
Posté par pinky . Évalué à 5.
Ce lien concerne un module qui ne fait pas partie de Odoo, un module tiers de l'OCA. Je n'ai pas creusé plus que cela, mais probablement un bug dans leur code qui court-circuite l'ORM standard. L'ORM Odoo traite bien les décimal correctement. Voici un test fait rapidement (sur une branch master-nochange-fp, mais le comportement est le même depuis les premières versions de Odoo): http://tinyurl.com/y263r7cx
Faire cela amène les même désavantages que d'utiliser un float; si tu ne travailles pas avec la bonne précision, il faut alors quantize() manuellement à certains endroits dans le code. (e.g.lors de comparaisons, ou avant de storer, calcul de taxes, …)
Le débat revient juste à choisir quel côté du trade-off on préfaire:
- float: performance, flexibilité / facilité de code
- decimal: permettre de gérer des nombres avec plus de 16 chiffres
Odoo a prit le parti que les nombres à plus de 16 chiffres n'apparaissent pas dans les domaines concernés par les decimal (typiquement la compta). Mais, même si à l'avenir, dans un domaine fonctionnel particulier, on a vraiment besoin de gérer des très grands nombres, rien n'empêche d'utiliser un type Decimal dans le code (et les représentations DB sont Numeric); c'est juste que ce cas ne s'est jamais produit.
PS: je t'invite a chercher sur google "tryton issue quantize" pour prendre du recul --> les deux approches ont leurs inconvénients.
[^] # Re: float vs decimal
Posté par Cédric Krier (site web personnel, Mastodon) . Évalué à 5.
Je ne pense pas que ce soit un bug dans le code de l'OCA. En fait, il y a même un commentaire dans le code d'Odoo qui explique le bug: https://github.com/odoo/odoo/blob/12.0/odoo/fields.py#L1334 Dommage que le bug n'ait pas été corrigé depuis sa découvert il y a 3 ans (le 12/4/2016).
J'aurais préféré voir un test unitaire qui garantie la conformité dans le temps et pour tous les cas limite.
De plus j'imagine que le test est fait avec un champ Float et un nombre de décimal hard codé.
Pas nécessairement, par exemple le cas classique de:
>>> 0.3 - (3 * 0.1)
-5.551115123125783e-17
n'existe pas avec decimal et sans arrondir:
>>> Decimal('0.3') - (3 * Decimal('0.1'))
Decimal('0.0')
Mais pour moi, c'est une bonne chose que le développeur arrondisse explicitement quand il le veut et doit et que le framework lui dise quand il a oublié.
Pas vraiment. Déjà Decimal n'est pas tellement plus lent (environ 2x) que float en Python3 puisque c'est écrit en C. Pour la flexibilité, Decimal l'est plus puisqu'on peut configurer le context comme on veut alors qu'avec float ça dépend du hardware. Pour la facilité de code, je pense qu'il est justement plus simple que le framework lève des exceptions quand on fait quelque chose de pas correcte qu'il n'essaie de corriger implicitement.
Mais bon, je ne pense pas que j'arriverai à te convaincre car nous ne mettons pas la priorité sur les même objectifs. Je préfère l'exactitude qui peut être quelque fois contraignante à la facilité qui cache des approximations.
Cette recherche ne donne (à part l'issue Odoo où justement les gens prennent Tryton en exemple pour demander qu'Odoo utilise les Decimal) que 2 issues.
La première est invalide car c'est quelqu'un qui appel quantize sur un dict (on peut parler typage statique avec Python 😉)
La seconde est justement le cas de quelqu'un qui veut utiliser des nombres avec plus de décimal que ce que le context par défaut de Python ne supporte. Donc dans ce cas, il suffit de changer le context pour que ça marche (évidement au détriment de performance).
[^] # Re: float vs decimal
Posté par pinky . Évalué à 4. Dernière modification le 24 juillet 2019 à 19:21.
Tests des champs float & monetary:
https://github.com/odoo/odoo/blob/12.0/odoo/addons/test_new_api/tests/test_new_fields.py#L430
[^] # Re: float vs decimal
Posté par Cédric Krier (site web personnel, Mastodon) . Évalué à 3.
Et bien il manque un test avec un model qui a un champ Function et un champ related pour 'currency' comme l'indique le commentaire.
[^] # Re: odoo est-il encore libre ?
Posté par pinky . Évalué à 10.
D'une manière générale, à chaque nouvelle version, Odoo Community reçoit énormément de nouvelles fonctions et améliorations. On garde le même ratio depuis quelques années: 80% de nos développements sont sur Odoo Community (la version open source), et 20% sont sur Odoo Enterprise (les extras features propriétaires).
Bien sûr, à chaque nouvelle version, on améliore beaucoup de features. Il y a donc des comportements qui changent, et des corner cases qui peuvent ne plus être supportés. C'est une gestion de produit normale, Odoo s'améliore très vite, cela induit beaucoup de changement. Mais notre mentalité est de rester le plus compatible possible (très peu de suppressions, même s'il peut y en avoir), et ce qui est open source reste open source.
Dans tout ls cas, il n'y a aucune volonté de diminuer la version open source par rapport à la version propriétaire. Au contraire; les revenues générés par Odoo Enterprise sont majoritairements investis pour améliorer le version community. (raison pour laquelle Odoo Community avance bcp plus vite que tous les autres acteurs libres)
Plus d'infos sur un blog publié récemment: https://www.odoo.com/blog/odoo-news-5/post/odoo-community-enterprise-532
[^] # Re: odoo est-il encore libre ?
Posté par ZeroHeure . Évalué à 4. Dernière modification le 23 juillet 2019 à 16:05.
Pour l'utiliser depuis longtemps, je trouve que c'est le contraire. La version 13 qui sort en novembre reçoit d'ailleurs en CE des modules qui étaient jusqu'alors en entreprise suivant les principes :
Tu peux lire à ce sujet la roadmap de la version 13 et un blog de Fabien (pinky) qui explique le nouveau cheminement d'Odoo.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: odoo est-il encore libre ?
Posté par sisalp (site web personnel) . Évalué à 4. Dernière modification le 25 juillet 2019 à 14:55.
Je pense que que vous avez tous les deux raison, mais vos attentes sont différentes.
Il faut distinguer ce qu'est un framework et un produit
Odoo CE est un framework open-source et. en effet, il s'améliore de version en version.
Si on cherche à utiliser Odoo CE comme un produit dans la continuité d'oDoo V8, en effet, de plus en plus de fonctions essentielles manquent.
Je ne suis pas d'accord avec l'assertion "ce qui est essentiel à l'entrepreneur va dans la version libre". Ca ne figure pas dans les annonces officielles et la comptabilité est le contre exemple. A la base de toute gestion fiable, elle ne figure que dans Odoo Enterprise.
Plus généralement, il faut aussi distingeur ce qu'est un produit et une solution sur projet.
Odoo Enterprise est le produit propriétaire construit sur Odoo CE. Le produit a un code à périmètre défini, une roadmap et une gouvernance, une offre de service et un contrat générique (le même pour tous). Le financement est un investissement amortissable. Bénéfice : coût/performance.
La solution sur projet se base sur Odoo CE et intègre à la demande un bouquet de modules, par exemple, ceux de l'OCA. Le cahier des charges remplace la roadmap et la gouvernance. Le contrat est négocié au cas par cas. Le financement est fait par le client. Bénéfice : flexibilité et proximité.
Vouloir utiliser Odoo CE comme un produit amènera des déconvenues.
Chacun interprète ces règles selon le biais introduit par sa position dans l'écosystème.
Pour ma part mon biais est de privilégier les produits libres à gouvernance collaborative.
Quel est le vôtre ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.