xulops a écrit 315 commentaires

Voila bien le problème, la majorité a-t-elle toujours raison ? La diversité a-t-elle le droit d'exister ?

Parce que la majorité des devs utilisent un debugger, faudrait que ce soit la seule façon de coder ? Tu as une drôle de conception du libre. Et puis je ne vois pas trop pourquoi tu fais tant de prosélytisme. Les devs qui n'utilisent pas de debugger, ça te dérange ? c'est de la jalousie ? un besoin irrépressible que tout le monde fasse comme toi ? Un mesquin sentiment d'être dans la meute du côté des plus forts ? Un bon psy peut sans doute t'aider, tu sais.

Un sondage, bof ? Le résultat importe peu, et il ne serait sûrement pas le même pour les devs PHP que pour les devs java.

Et pour finir sur le sujet, j'ai longtemps fait du RPG sur AS/400, je n'ai jamais utilisé le debugger sur mes propres programmes, mais je l'utilisais souvent sur les programmes écrits par d'autres (qui n'étaient pas toujours sains d'esprit, et c'est peu dire). Donc tu vois, contrairement à toi, je ne suis pas sectaire, c'est une question d'utilité dans un contexte donné. En PHP, j'ai le bonheur de ne pas avoir à modifier le code des autres, ou très peu, pas besoin de debugger pour mes propres devs, voilà tout.

Merci "tonton th" pour cet éclairage. J'aurai plutôt nommé ça cpsav que cpold, je crois qu'on a tous fait ça au moins une fois dans notre vie de dev.

"devnewton" est donc bien à côté de la plaque, à généraliser ce que lui pense être de mauvaises pratiques, en tentant d'en glisser une vraie parmi des fausses. Basse pratique assez courante, son debugger a sans doute buggé. Il va encore moinsé, mais finalement rien à battre, ça confirme juste que tous les sites ont leur lot de boulets, quelque soit le sujet.

Bon allez, je fais l'effort de te répondre une fois de plus ::

je n'ai pas besoin de debugger, je ne fais jamais de bug

Je n'ai jamais eu besoin d'un outil dédié (un debugger) pour trouver et corriger mes bugs. On parle bien de PHP, hein, c'est bien le sujet de la dépêche. Dans d'autres langages, c'est peut-être différent, j'en sais rien, vu que je ne code qu'en PHP (sauf à appeler javascript un langage).
Si tu trouves un endroit où j'ai dit que je ne faisais jamais de bug, tu viens le montrer, faut assumer dans la vie.

le cpold est plus efficace qu'un gestionnaire de version

Aucune idée de ce qu'est cpold, et j'ai un peu la flemme de chercher là. Et comme on n'a nul part parlé de gestionnaire de version, le gars il dit qu'il ne voit pas le rapport avec la choucroute.

les frameworks c'est nul, je préfère tout coder moi même.

C'est mon avis, que je partage avec moi-même. Si ça te défrise, tant pis pour toi.
Je déteste les frameworks, j'utilise des classes ou libs faites par d'autres, mais avec parcimonie et en regardant comment c'est fait. Oui, je préfère tout coder moi-même, et mes clients ne s'en plaignent pas, au contraire. Tout coder soit même a ses avantages.

Comme je le disais, ça manque cruellement de tolérance ici. Utilise donc ton debugger si ça t'aide, mais n'impose pas aux autres ta façon de développer.

Ben dis donc, ça manque singulièrement de tolérance ici… la meute des utilisateurs de debugger se sont sentis attaqués ? Il n'y avait pourtant pas de raison.
Je pensais que les utilisateurs de Linuxfr, compte-tenu du sujet principal du site, avaient un peu plus d'ouverture d'esprit et de tolérance que les utilisateurs de sites lambda. Mais je me rends compte que finalement la nature humaine engendre les mêmes travers sur tous les forums, blogs, commentaires… quel que soit le sujet.
Pas grave, hein. Restez donc entre vous, je continuerai à lire (et écouter dans le cas présent) les excellentes dépêches sans intervenir dans les commentaires, c'est mieux pour tout le monde.
Ad astra.

Oui et non, on n'est pas tous pareils, et on ne fait pas tous la même chose.
Un dev symphony a sans doute davantage besoin d'un debugger qu'un autre.
Dire qu'un dev qui n'utilise pas de debugger est aveugle, c'est faire fi de la diversité des développeurs et de la diversité des méthodes de développement.

Donc ça fait 20 ans que je m'en fous de ce qui tourne en prod, merci de me l'apprendre, haha. Ca va faire plaisir à mes clients.

Pour préciser ma pensée (et entrer dans ton troll du samedi), je n'ai jamais eu besoin d'un debugger parce que je sais comment se déroule mon programme, quel est le contenu des variables, et ce à tout moment. Un cerveau humain qui émule un interpréteur, pour programmer, c'est quand même pratique, non ?

Chacun est libre d'utiliser un debugger ou pas, je n'ai pas de problème avec les gens qui en utilisent. Mais dire que celui qui n'en utilise pas est aveugle, c'est l'histoire de la poutre et de l'oeil.

Emission sympathique sur un sujet qui m'intéresse.
Les deux invités ont davantage l'air d'être des devs Symphony que des devs PHP purs et durs, car :

• c'est dommage de ne pas connaître le sebang PHP pour les scripts sh : #!/usr/bin/env php (ou #!/usr/bin/php dans la plupart des distribs) et de ne pas en voir l'utilité.

• dire qu'un dev qui n'utilise pas de debugger est un dev aveugle. Moi j'aurais dit l'inverse : un dev qui a besoin d'un debugger est un dev qui navigue en aveugle dans son code.

Aparté sur le short_open_tag déclaré "deprecated" : il est loin de disparaître, sauf à entendre hurler dans les chaumières. La base existante est énorme, et la désactivation de cette option sur un site a le malheureux effet secondaire d'afficher sans crier gare le code dans le navigateur (bonjour la sécurité). Comme il n'y a aucun (mais vraiment aucun) intérêt à taper systématiquement trois lettres de plus (<?php au lieu de <?), qu'on nous foute donc la paix avec le short_tag.

Merci pour ces précisions.

Pour les usages de R (que je ne connais que de nom) ça rentre sans doute un peu dans la case "spécificité".

De ce que je comprends, tu aurais pu faire ce projet en PHP/perl/lush si tu avais maitrisé ces langages sur le bout des doigts, et que le choix final de Python s'est fait parce qu'un gars le connaissait justement sur le bout des doigts. Ou je me trompe ?

Mon regard sur des projets passés est que parfois le(s) dev(s) perd(ent) beaucoup de temps à choisir le langage qui sera utilisé, change(nt) x fois avant de se fixer (ou pas) et qu'au final ça aurait été beaucoup plus vite de choisir un langage qu'il(s) maîtrise(ent) bien au lieu de tergiverser.
J'ai même bossé avec un cas gars sur un projet (lui le frontoffice, moi le backoffice) qui réécrivait tout le code dans un nouveau langage tous les deux mois juste parce qu'il voulait "jouer" et découvrir le dernier langage fashion du moment qu'il est super bien et tout et tout : très positif pour sa culture info, mais on a attendu longtemps le frontoffice terminé, et puis comme il n'est jamais arrivé, j'ai du le faire moi-même (en PHP bien entendu).

Mon "plus gros" projet, il a fait :

implé en php (pas satisfaisant)
implé en perl (c'était pas ça)
implé le lisp (lush pour être précis, toujours pas ça)
implé en python. Ah, voilà, là ça va \o/

Salut Kaos,

C'est off-topic, mais ça m'intéresse de savoir le pourquoi des "pas satisfaisant" et autres.

Je pose la question car je suis étonné (et curieux de nature). Moi j'ai toujours tout fait en PHP, mais note que ça aurait pu être un autre langage, c'est juste que c'est celui que j'ai maîtrisé à fond en premier, et je suis resté à mon premier amour.
Mais tu as l'air de dire qu'un projet s'accomode mieux d'un langage plutôt que d'un autre.

Je peux comprendre quand il y a vraiment un facteur spécifique, genre il faut que ce soit hyper-rapide donc Assembleur, ou usage obligatoire d'une bib dont le binding n'existe que pour un langage précis, … Or, pour 99% des projets que j'ai pu faire, avec un bon gros mix de devs web, scripts en batch, daemons, client lourd, je ne me suis jamais retrouvé bloqué par mon langage par défaut, et changer de langage n'aurait rien apporté de mieux, ni en facilité de dev ni en qualité du résultat.

Par exemple, là je suis en congé, et ça fait 3 jours que je suis sur le dev d'un serveur imap en PHP, pour aller avec les serveurs POP et SMTP que j'avais également fait en PHP il y a plus de 15 ans de ça. Je n'en suis qu'à un tiers de la RFC, putain c'est long… Ce n'est certes pas "conventionnel" de faire des daemons linux en PHP, mais pourquoi pas ? je ne vois pas ce que m'aurait apporté de plus le fait de le faire en Python, en Perl, en C ou en perlimpinpin ; ça tourne, ça roule, ça tient la charge. Un algo est un algo, le langage est juste une façon de faire comprendre ce qu'on veut que le proc fasse.

Donc voilà, pourquoi pour toi Python a été plus adapté sur ce big projet ?

Ce n'est pas "soit ou soit", c'est les deux mon capitaine !
Il y a trop de monde sur Terre, et qui consomment et polluent trop… en moyenne. Qu'un ricain consomme et pollue 20 fois plus qu'un africain ne change pas le résultat, surtout quand la tendance est à vouloir tous faire comme les ricains.

Si tu veux dire qu'en habitant dans le Larzac tu as moins l'impression qu'on est nombreux sur Terre par rapport à moi qui vit dans une ville de 12 millions d'habitants, heu… oui, le ressenti n'est sans doute pas le même. Mais on est assez grand pour passer au dessus de ça et regarder à plus grande échelle, non ?

Le réchauffement climatique, il est bien du aux activités humaines (combustion des matières fossiles notamment), et on en parlerai pas si la population globale était faible. Comme je le disais un peu au dessus, quelques centaines de milliers de gens sur Terre pourraient polluer autant qu'ils veulent sans impact notable sur l'écosystème. Les problèmes surviennent quand plusieurs milliards de gens consomment et polluent.

C'est vrai qu'un habitant des Etats-unis et du Bangladesh ne laissent pas la même empreinte, ça n'invalide pas le fait qu'on est déjà trop nombreux. L'un n'empêche pas l'autre.
Il y a beaucoup de gâchis dans certains pays, et de la famine dans d'autres, ce n'est pas un scoop.

Comme tu le cites, 2700 calories produites par habitant par jour, en perdant seulement le tiers, il reste 1800 cal par jour et par personne. Or les besoins nutritionnels d'un adulte sont entre 2400 et 2600 cal par jour (dixit le premier lien google sur le sujet, je n'ai pas cherché des heures).
Certes les très vieux et les enfants mangent moins, et les ados trois fois plus, donc en moyenne, au doigt mouillé, le besoin doit être autour de 2000, soit déjà au dessus des 1800 fournis au mieux.

Bref, on est trop nombreux.

Moi à ta place j'irais faire un tour dans le bios (ou ce qui en tient lieu) histoire de voir s'il n'y a pas un truc du genre "économie d'énergie" qui désactiverait la carte graphique si pas d'écran branché au boot. Sait-on jamais…

En effet, dans 100 ans il sera mort, et moi aussi (et même bien avant). Du coup la question n'est sans doute pas destinée à nous-même, mais plutôt à nos enfants, … enfin, aux vôtres, puisque moi je m'en fous, je n'en ai pas.

Mais la question est intéressante et la réponse est fortement lié à l'évolution de la population.
S'il n'y a que quelques centaines de milliers de gens sur Terre, sauf annihilation totale à coup de bombes nucléaires, peu importe combien ils consomment, polluent, … il y aura toujours un endroit vivable pour eux.

A 10 milliards sur notre caillou, c'est une autre histoire. Alimenter tout le monde est actuellement un jeu d'équilibres que le réchauffement climatique, entre autres, peut (va) mettre à mal.
Bref, on est trop nombreux sur Terre, donc ça va forcément merder à un moment où à un autre.

Une petite note d'optimisme : à voir si la natalité ne baissera pas naturellement dans les décennies à venir, comme c'est le cas dans beaucoup de pays "développés", sans aller jusqu'à des mesures draconiennes comme le fût la politique de l'enfant unique en Chine.

Petit aparté sur le cas de la Chine : la politique de l'enfant unique est révolue puisque maintenant ils peuvent avoir 2 gosses gratos, et même davantage si les parents sont riches, car c'est le système inverse des allocations familiales françaises : plus tu as de gosses, plus tu payes. Deux, c'est gratos, mais beaucoup de familles se limitent à un gosse (le minimum pour sauvegarder la face) car élever un gosse coûte cher en Chine.

Tu as raison.
On ne parlait juste pas tout à fait de la même chose, je voyais ça pour un usage proche de celui de la Suède, à savoir s'identifier sur des sites étatiques ou assimilés, là où s'identifier a vraiment un intérêt, pas pour les sites lambda comme linuxfr.
Mais il ne faut pas se leurrer, quand cette identification sera mise en place (et elle le sera, ce n'est qu'une question de temps), il y aura forcément ensuite une loi qui sera pondue pour que ce soit obligatoire, y compris sur les sites lambda, au nom de la lutte contre le terrorisme informatique (l'excuse qui fait tout passer).
Il y aura quelques avantages, par exemple il faudra assumer ses propos sur les forums et autres, fini de se cacher derrière un pseudo, mais il y aura aussi risque de dérives de l'état.
Donc tes craintes sont fondées, non pas sur l'usage initial, mais sur l'usage détourné à long terme, compte tenu de la nature des hommes de pouvoir. La France n'est pas la Suède, la transparence n'est pas dans nos moeurs.
C'est l'histoire du couteau qui sert à couper la nourriture, ou à tuer quelqu'un. L'outil peut être utilisé à bon escient, ou pas.

Non, avec un truc type GPG, ce n'est pas le cas. Chaque site contient ses utilisateurs, mais personne n'a la liste complète.

Oui, si le but est de s'authentifier. Non, si le but est de s'identifier. Ce sont deux besoins différents.

Le croisement de fichier fait peur. C'est à double tranchant. L'état sera bien plus efficace pour traquer les abus, les personnes en difficulté et les opposants politiques.

Ca dépend… de l'usage qui en est fait; sans doute.
En Suède ça se passe bien, c'est efficace (l'administration suédoise est globalement largement plus efficace que l'administration française). Que les abus (des politiques surtout) et personnes en difficulté soient traqués plus efficacement me semble être plus une qualité qu'un défaut. Pour les opposants politiques… heu, je ne vois pas ce qui pourraient être fait de plus que ce qui se fait déjà (les RG ont déjà des dossiers bien remplis), et là aussi il n'y a pas de cas en Suède venant conforter cette idée.

Le sujet est "Authentification et identité numérique…", donc c'est un peu le but d'avoir un ID unique qui soit facile à utiliser pour s'identifier sur les sites sur lesquels une identification est nécessaire.

Pour le fichage, je ne vois pas ce que ça ajoute de plus que ce que l'état connait déjà. Tu as d'ailleurs déjà quelques ID uniques (numéro de sécu, CNI, numéro de passeport…), et des moyens de t'identifier (france connect et consorts), c'est juste que c'est un peu le bordel, donc pas simple d'utilisation.

C'est un sujet déjà maintes fois abordé, et le résultat est que la France fera comme elle fait toujours : filer le marché juteux (sur le dos des contribuables) aux copains des grosses SS2I avec un résultat à la hauteur de l'appli stopCovid, c'est à dire proche du néant.

Il ne faudrait surtout pas pour une fois s'inspirer de ce qui se fait ailleurs et qui fonctionne.

Par exemple en Suède, il existe depuis belles lurettes une infrastructure nommée BankID qui répond aux besoins. Voila comment ça fonctionne :

En premier, il faut un personummer : numéro personnel, genre de numéro de carte d'identité qui fait 12 chiffres (facile à retenir puisque 8 chiffres sont la date de naissance, et les 4 autres un numéro séquentiel des demandes pour cette date). En France on a le numéro de sécu qui s'y rapproche. En Suède, tout le monde à un personummer, et donc une carte d'identité suédoise, y compris les étrangers qui s'y installe (avoir une carte d'identité suédoise ne veut pas dire qu'on est de nationalité suédoise).

Ensuite il faut une application sur smartphone, application a un code secret pour se lancer (6 chiffres).

Si on veut s'authentifier sur un site quelconque (sa banque, les impôts, aides sociales, payer un amende, rechercher un job sur le site du pole emploi, …), le cheminement est le suivant :
- sur le site, je tape mon personnummer (ce n'est pas un secret).
- le site contacte BankID (intermédiaire de confiance) et me dit de lancer l'appli BankID sur mon smartphone.
- je lance bankID sur le smartphone, tape mon code secret (6 chiffres), et l'appli m'indique que le site xxx que je consulte veut que je m'authentifie.
- je dis ok. C'est terminé.

Le site en question ne connait que mon personummer et BankID lui a confirmé que c'est bien moi.
Le tiers de confiance sait que je me suis authentifié sur tel ou tel site. Ca peut être vu comme un problème de confidentialité, mais c'est censé être géré par l'état, qui peut déjà consulter les logs des FAI, donc bon…

Paraitrait-il que l'appli BankID nécessite les API google. Je n'ai pas vérifié, et s'en inspirer ne veut pas dire faire exactement pareil. Il y a moyen de faire un truc propre et léger.

J'entends déjà hurler les "c'est cool ton truc, mais je n'ai pas de smartphone, comment je fais ?". Il existe aussi des genres de mini-calculettes qui demande un code pin (secret, initialisé au départ) qui génèrent des nombres uniques et temporaires (jetons), c'est également ce qui est utilisé en Suède, fournie gratuitement et qui tient dans la paume de la main. C'est principalement utilisé pour valider les paiements en ligne.

Mais mon côté pessimiste me fait dire qu'on va réinventer la chose, pour très cher et en moins bien. La french touch quoi.
En cadeau : ma main velue avec une calculette fournie par Sewdbank.

C'est super de l'avoir fait, et de partager.

J'ai une question à propos de la killer feature, si chacun peut partager son écran et que ça s'ouvre automatiquement sur tous les écrans, est-ce que ce n'est pas un peu le bordel avec une classe ou un groupe, disons, un peu dissipé ou espiègle ?

Pour de la formation, dans l'idéal il faudrait que le prof / formateur puisse choisir qui partage son écran avec tout le monde à un moment précis. Faudrait donc en quelque sorte une appli maître qui commande les applis des postes. Mais ton besoin est peut-être différent.

Pour le front office (on ne parle que ce celui-là, puis que le backoffice n'est pas multilingue, mais c'est pareil), faut distinguer le contenu statique du contenu dynamique.

Le contenu statique est créé / ajouté par le développeur au moment où il code le truc. S'il devait faire des aller-retours entre son code et la BDD à chaque fois qu'il doit ajouter un libellé, il va vite péter un câble. Donc la partie statique est presque toujours en fichiers qui n'évoluent pratiquement plus une fois le dev terminé. Sur la façon de stocker en fichier, il y a plusieurs écoles.

Le contenu dynamique, il est créé / ajouté par les utilisateurs du site, ou par des personnes en charge de la rédaction, bref pas par des devs, et ils ne savent bien souvent même pas comment sont stockées les données. Dans la grande majorité des cas, c'est stocké en base, avec un index sur la langue du contenu.

Ce sont surtout des considérations pratiques : vitesse/confort de dev pour le statique, facilité de récupérer directement le contenu dans la bonne langue en dynamique.

Maintenant, une base de données, ce n'est qu'un ensemble de fichiers, dans un format particulier, que va lire un moteur de requêtes.
Le meilleur exemple (le plus simple), c'est un fichier VSAM sur AS/400, le fichier peut contenir plusieurs membres, chaque membre est comme un tableau avec colonnes de largeur prédéterminée, par exemple ID de la colonne 1 à 5, langue de la colonne 6 à 14, titre de la colonne 15 à 89, etc.
A côté de ça, tu as des petits fichiers de définition d'index que le moteur DB2 utilise pour retrouver très rapidement que la ligne avec l'id 34564 est à la 23464 ligne du ficher. Un seek, un read, et c'est fini (je simplifie un peu quand même).
Bref, si tu stockes en fichier, tu as un code pour lire le fichier, en extraire la valeur (souvent un fichier de type cle/valeur). Si tu stockes en base, c'est le moteur qui fait le boulot.

Niveau performance, tant que le contenu statique ne fait pas des Mo, la solution fichier est la meilleure car le fichier est lu une fois et reste en cache tout le temps. Si c'est stocké en base, il est possible que le moteur dégage la table en question du cache si d'autres requêtes bien bourrines bouffe la ram jusqu'au paramètre de cache défini. Du coup, le statique en fichiers gagne sûrement un peu niveau IO.
Pour le dynamique, c'est censé gonfler dans le temps, c'est bien en base.

Les gens ne répondent généralement pas à ce genre de question, va savoir pourquoi … je vais essayer.

Ce que j'ai développé est assez complet et surtout très adapté aux besoins (c'est l'un des buts de le développer soi-même). Donc te donner un prix ne serait utile que si je te donne aussi le descriptif complet des fonctionnalités ce qui serait fastidieux (par exemple chaque tablette peut contrôler le son diffusé dans le resto, changer de morceaux, volume…).
On va donc faire plus simple, en ne prenant qu'un (déjà gros) morceau plus facile à décrire : la saisie de commande, son traitement et son encaissement.

Donc en gros :
- une interface web
- responsive (usage principal sur tablettes, mais aussi smartphone à l'occasion) et prévue pour un usage tactile,
- Une page principale pour la saisie qui affiche les produits par catégories (plats principaux, boissons, desserts), on change de catégorie en cliquant sur un bouton, ça change la liste des produits. Doit figurer la liste des produits de la commande en cours avec prix et quantités, et les boutons qui vont bien pour les modes de paiement (en espèce, Weixin (Wechat) ou Zhifubao (alibaba), le numéro de commande, l'origine de la commande (en magasin ou par internet, principalement Meituan et eleme en Chine), mise en attente du paiement (il y a des gens qui paient à la commande, d'autres après avoir mangé), et sur le lien de la deuxième page, le nombre de produits à préparer dans la cuisine concernée.
- une seconde page avec la liste des commandes en cours pour la cuisine concernées. Un bouton pour dire que c'est donné au client, les autres lignes sont affichées en petits et en gris mais permettent de faire l'encaissement si besoin (des clients commandent à une cuisine, mais paient à l'autre, ça arrive).
- le tout en chinois, mais c'est anecdotique, quoique pratique puisque le texte est souvent plus court.

S'il ne faut faire que cela, avec dans la partie administration la gestion des catégories et des articles (ordre d'affichage, prix, actif), le tarif que je demanderais se situerait entre 2000 euros et 3000 euros.
Certains pourraient trouver ça cher : déjà je ne prétends pas être le moins cher du marché, la qualité et le bon relationnel se paie aussi, puis il y a du boulot à faire quand même, et ils sont libres de prendre un autre prestataire moins cher.
Certains pourraient trouver que ce n'est pas cher du tout : j'ai l'habitude de développer des trucs comme ça, c'est du boulot mais ça va finalement assez vite, et je vis dans un pays où le coût de la vie est faible.
Chacun voit midi à sa porte.

Je tente d'insérer une image de la page principale :

J’arrive un peu après la bataille, désolé, mais répondre un tartine comme celle-là demande un peu de temps pour se décider (à y consacrer le temps, justement) et à la rédiger (surtout avec mon clavier qwerty, merci iBus, tu plantes de temps en temps avec le chinois mais je t’aime quand même).

J’ai lu beaucoup de commentaires disant que 2000 euros par an, c’est que dalle au regard du confort et de la sécurité (sauvegardes, remise en route après désastre…). Ca se discute, et se comprend surtout si le CA est élevé, que la boîte se porte bien. Dans le cas évoqué, c’est clairement énoncé que c’est cher pour lui, et précisé ensuite que la situation financière de la boîte n’est pas rose, en partie à cause du confinement. De plus, le gars a un désir de changement. Peu importe ses motivations, un désir de changement se respecte, se doit d’être pris en compte.
Je suis donc d’avis de ne pas le dissuader de changer, sous prétexte que 2000E/an c’est peu. Personnellement, pour une TPME de deux personnes (le comptable ne doit pas se connecter souvent), je trouve même que c’est très cher.

Je vais vous raconter une petite aventure de la fin d’année dernière, ne m’en veuillez pas si c’est long :
Je vis en Chine, et j’ai décidé, avec une personne chinoise, d’ouvrir un petit resto vendant à la fois des nouilles (de blé, de riz, …) et des pâtisseries (pancakes, muffins, gaufres…). Les lois chinoises étant particulièrement inexistantes pour ce genre d’activité, pas de logiciel de caisse infalsifiable, pas de TVA, pas de taxes à payer, … ce que tu gagnes est direct dans ta poche.
Voulant faire des statistiques de ventes, par produit, par jour, tenir un peu un stock de matières premières, des dépenses, j’ai développé un site web pour usage en plein écran sur tablette android. Deux tablettes, une par cuisine (une cuisine pour les nouilles, une cuisine pour les pâtisseries),et éventuellement saisie des commandes en salle sur mobile. Le « serveur » est un simple Raspberry Pi4 (Apache/PHP/Maria DB). Je n’ai pas cherché de solutions existantes pour deux raisons : je voulais m’amuser à le faire moi-même, et un truc qui permette la saisie de commandes de plusieurs endroits en affectant les lignes aux cuisines respectives, avec un cas spécial pour les articles pouvant être fournis par les deux cuisines (boissons par exemple), ce n’était pas gagné. Et j’en rajoute même une troisième : pas question de mettre 2000 euros par an pour ça.
Tout ça pour dire, une petite entreprise de deux ou trois personnes, il n’y a pas besoin d’une salle serveur et de beaucoup de matériel. Deux tablettes et deux raspberry pi4, surtout en Chine, ça ne va pas loin (de mémoire moins de 300 euros). J’ai bien écrit deux Raspberry, parce que justement en cas de panne, ça prend 2 minutes à changer. Pour les sauvegardes, un script sur le Pi qui dump la base de données et copie dump, codes et logs sur une clé USB toutes les 5 minutes pour la sauvegarde locale. Le Pi de secours a déjà une carte SD avec tout installé. Si la carte SD de production plante, changement de carte SD, recopie des fichiers de la clé USB et ça repart. Il faut aussi des sauvegardes régulières vers un site distant, dans mon cas un rsync vers un serveur toutes les heures. Ce serveur distant est aussi backupé, mais là on s’éloigne du sujet.
Donc voilà, héberger en local demande bien entendu des compétences, mais pas un investissement financier énorme, c’est même plutôt ridicule. Un raspberry Pi peut très bien faire tourner ce genre de site pour plusieurs utilisateurs simultanés. Je n’ai pas testé à fond, mais dans mon cas il glandait 99.9999 % du temps. Aucun problème pour mettre une instance Dolibarr dessus.

Pour revenir au cas de l’OP, je comprends très bien qu’il ne veuille pas non plus y mettre 2000 euros par an, surtout s’il ne mange que des pâtes tous les jours. Et je ne lui conseillerai pas d’héberger en local s’il n’y connaît rien, même si c’est tout à fait possible sans se ruiner mais en investissant beaucoup de temps dans l’administration système.
Il ne lui reste donc uniquement l’offre cloud : une instance de l’ERP qu’il choisit, et dont il n’aura pas à s’occuper de la maintenance et des backups. Mais encore faut-il qu’il choisisse !
Le choix se fait avant tout sur l’adéquation de ses besoins avec les fonctionnalités de l’ERP. Puis vient le prix, et ensuite d’autres critères comme l’ergonomie, la facilité de joindre un interlocuteur, …

Pour l’adéquation des besoins, c’est difficile de le conseiller, on n’en sait pas assez sur ses besoins réels, on sait juste qu’Odoo Entreprise répond aux besoins actuels, mais pas Odoo Comunity.
Pour le prix, 2000 c’est trop, donc exit Odoo (pas tout de suite, une migration se prépare). Si Dolibarr répond à ses besoins, je pense qu’il doit partir là dessus. C’est stable : j’ai des instances Dolibarr pour des clients et moi-même, et je n’ai jamais eu le moindre pépin (touchons du bois), ni au jour le jour, ni lors des mises à jour. La communauté d’utilisateurs français est grande, le développement est actif, quasi tout est présent d’office, pas d’arnaques du genre « le core est gratuit, mais les plugins sont payants ». Dernier avantage et non des moindres, les instances sont peu chères, je cite : « commencent en dessous de 10€ par mois et des offres à 40-50€ par mois lui semblent bien complètes ». Personnellement je ne vois pas la différence entre une offre à 10 euros et une à 50. J’espère que les deux offrent une sauvegarde qui marche (sinon ce n’est pas une offre). Peut-être la différence se situe dans le délai d’intervention en cas de problème. Il doit exister des offres intermédiaires, genre 25 euros par mois, qui doivent tenir la route (s’il n’y en a pas, je lui fait, je ne suis pas à une instance Dolibarr près), et qui le ferai passer de 2000 euros par an à 300. 1700 euros d'écart, pour beaucoup de gens c'est un mois de salaire.

Reste le gros point de la migration, et là aussi ça dépend de son activité, de son envie, de son temps disponible, et de l’aide que peut apporter l’instanceur (je ne suis pas sûr que ce mot existe, mais tout le monde a compris que je parle de l‘entité qui propose l’instance). Dolibarr a des fonctions d’imports qui sont assez faciles à utiliser, mais faut prendre le temps de bien faire les choses et vérifier que tout est ok à la fin.
De toute façon, faut rester sur Odoo tant que tout n’est pas 100 % ok avec le nouvel ERP, et ça peut prendre du temps, longtemps.

Mon plus long commentaire… mazette, je vais me coucher.

Je n'ai malheureusement pas le plaisir de connaître Chonchon.
A mon prochain retour en France (si un jour ce satané virus le permet), on ira boire un pot ensemble et tu me présenteras ?
S'il est vraiment aussi efficace qu'un collègue faut penser au clonage ou à faire un élevage, il y a des sous à se faire là.

Et il aide vraiment dans les 9 autres % (estimation pifométrique mais sûrement pas très loin de la réalité, en fait ça dépend du-dit collègue) alors que la peluche, elle te laisse dans la merde.

Si ça peut aider…

Quand je bossais en équipe, si un bug me bloquait plus de 5 ou 10 minutes, je demandais au collègue à côté de moi si je pouvais lui expliquer mon problème (et il faisait pareil quand il était bloqué).
Dans 90% des cas, le fait d'expliquer la situation permet de trouver le problème, car ça oblige à prendre un peu de recul, à reformuler les choses pour les rendre compréhensibles à l'interlocuteur.
Dans 9 autres % des cas, c'est le collègue qui trouve, car c'est bien connu qu'il y a toujours plus d'idées dans plusieurs cerveaux que dans un seul.
Dans les 1% restants, on galère à deux.

Un exemple de truc con sur lequel on a galéré : un éditeur (je ne me souviens plus lequel, peut-être gedit) qui faisait la différence entre un espace et la combinaison ALTGR + espace (tapé accidentellement car de mémoire sur le clavier français faut faire ALTGR 5 pour choper l'accolade, et la touche ALTGR a été relachée trop tardivement), et l'interpréteur aussi car il plantait avec erreur de syntaxe, sauf qu'à l'écran, rien ne permettait de faire la différence entre ces deux caractères. J'ai perdu deux heures là dessus pour trouver qu'un espace n'était pas un vrai espace.

Maintenant que je bosse seul, je continue un peu schizophréniquement à appliquer cette méthode : j'imagine un interlocuteur fictif auquel j'explique ce que je veux faire, … et ça marche (dans 90% des cas, ce qui est déjà pas mal).