Guillaume Maillard a écrit 268 commentaires

Ces formats existent plus ou moins, on peut citer pour les factures : UBL, XML Invoice de GS1, FacturX… , pour les écritures comptables: le FEC, etc… OpenConcerto en implémente quelques
unes. La difficulté réside dans les relations entre les éléments, les structures sont biens différentes d'un logiciel à l'autre. De plus, faut-il normaliser sur "le moins disant" ou sur l'implémentation la plus complète?
En attendant un "standard" nous avons développé l'import depuis quasi toutes les solutions du marché (MS Dynamics, Cegid, Sage, EBP, Ciel, Odoo, Dolibarr… et d'autres moins connus)

Concernant la confiance et la pérennité financière, nous avons dépassé les 20 ans d'activité et ne manquons pas de travail. Une bonne partie des sociétés avec qui nous travaillons et pour lesquelles leur ERP est un point critique, prennent notre contrat de maintenance. A priori, elles semblent satisfaites.

L'export FEC étant obligatoire, comment aurions nous pu ne pas l'intégrer? ;)
(cf https://www.openconcerto.org/fr/comptabilite.html)

Concernant la 2035, vous devriez sans grande difficultés retrouver les chiffres qui vous intéressent via le 2033.

Ne sachant pas ce qu'est un "code hyper disponible", je ne sais pas ce que l'on peut proposer de mieux que ce que l'on propose déjà, à savoir un dépôt libre d'accès et une licence libre (GPL).

Concernant la documentation, le guide PDF téléchargeable d'une vingtaine de page est suffisant pour démarrer. L'achat du manuel (papier) est comme pour un grand nombre de projet open-source, le moyen le plus simple de nous soutenir.

Le code est accessible depuis https://code.openconcerto.org (lien de la dépêche), suite à de nombreuses tentatives de hack, nous avons installé il y a 2 ans un filtrage par IP pour bloquer certains pays et les accès depuis un VPN.

Comme vous l'indiquez, tout est sous licence GPL.

C'est tellement ancré dans nos esprits que nous avons oublié de le repréciser dans la dépêche comme nous l'avions fait dans les précédentes.

Vos remarques sont intéressantes, voici quelques éléments de réponse.

Je comprend très bien que le fait qu'une application web ne nécessitant pas d'installation est plus pratique à déployer, mais nous avons tout fait pour que cela soit rapide (moins d'une minute par poste). Une version portable est même disponible pour du "zero install".
En revanche, les applications "natives" restent toujours plus intégrées au système et bien plus véloces que leurs équivalents web. Pour l'instant ce n'est pas du tout un frein à l'adoption d'OpenConcerto. Le principal frein est sa gratuité, difficile de combattre le biais cognitif "plus c'est cher, mieux c'est".

Nous travaillons depuis déjà un bon moment sur la "version web" du logiciel et sur un client léger, ils vous sembleront donc peut être plus "moderne". Nous continuerons la version client-server, l'architecture actuelle permet d'avoir les 3 modes. 2024 semble une bonne année pour leurs sorties officielles.

Concernant la gestion de production, ce n'est pas un domaine d'activité simple à séduire. Tout d'abord parce que les besoins sont très différents en terme de complexité d'une entreprise à une autre et que chaque type de produit à fabriquer requiert de fortes adaptations du système. Cependant le point important est que les entreprises faisant de la production sont déjà équipées en logiciel et sont très peu sensibles à l'open-source car satisfaites des solutions propriétaires dont le prix exorbitant les rassurent.

Je ne souhaite pas commenter votre dernière remarque vu qu'elle me semble particulièrement orientée sachant que que vous êtes partenaire Axelor et Cegid.

que se passerait-il si quelqu'un dénonçait ce genre de pratique auprès d'un procureur ?

Ce serait un bon moyen pour l'April de se faire connaître.
Bien que la devise affichée sur son site soit "Promouvoir et défendre le logiciel libre",
je serais surpris de les voir bouger.

Une autre solution, non dépendante de LibreOffice : jOpenDocument

Cette librairie Java permet de créer, manipuler et remplir des fichiers ODS/ODT..
et aussi de faire le "rendu" d'un fichier ODS en PDF (mais aussi l'impression et le rendu en bitmap).

Cette librairie est d'ailleurs utilisée par l'ERP OpenConcerto pour créer tous les documents via modèle ODT (un peu logique, vu que les auteurs sont les mêmes :) )

Tu as raison d'évoquer les travers des systèmes d'intégration, de compilation ou encore la paresse qui fait dire à certain qu'on est pas à 1Go près ni à 10ms près.

J'ajouterais à cette liste, les requêtes SQL inutiles/trop larges, les accès disques non cachés et la faible appétence à essayer d'optimiser quoique ce soit, sous prétexte que "c'est les autres le problème".

Il n'empêche que ce n'est pas une raison pour ignorer les problèmes liés à l'utilisation de certains langages (PHP, Lua, Ruby, Perl, Python…).

Si tu considères que la majorité des applications écrites dans ces langages passent leur temps à attendre (un top sur certains de mes serveurs tendent à prouver que non, mais bon, pourquoi pas l'envisager), utiliser un langage deux fois plus efficient permet de faire tourner deux fois plus de ces applications "patientes" sur un même serveur,
donc mécaniquement de diminuer le nombre de serveurs (on parle de centaines de millions, 3% de la consommation électrique mondiale).

on développe plus vite en Python qu'en Java.

J'aimerai savoir d'où ca sort… (a part d'un fort biais cognitif d'un développeur Python).

Oui, en effet, en compilant du code Python en code natif avec ces outils, les voyants reviennent au vert.
Ce qui m'inquiète le plus c'est le fait que tous les projets et les distributions que je vois passer, ainsi que la plupart des développeurs Python avec qui je peux échanger reste sur "l'interpréteur" standard, malgré souvent la connaissance d'alternatives.

Java a également des outils pour avoir des exécutables natifs, mais la encore, on peut constater que quasi personne ne les utilise.

Dommage qu'il n'y ai pas plus de communication à ce sujet sur le site officiel de Python ou lors des conférences.

Dommage que le programme soit déjà bouclé, j'aurais bien fait un speech sur l'efficacité énergétique catastrophique de Python, basé sur
https://www.devsustainability.com/p/paper-notes-energy-efficiency-across-programming-languages

En ces temps de crise énergétique et de réchauffement climatique, il est toujours bon de rappeler qu'un programme en Python consomme 30x plus d'énergie qu'un programme en Java… programme Java qui est déjà deux fois plus "consommateur" par rapport à des programmes écrits C ou Rust.

On peut VRAIMENT créer un équivalent d'AD et des outils d'administration comme ça ? des trucs que MS a mis des années à peaufiner ?

Les outils de Microsoft ne sont pas jeunes, Active Directory date de 1996… c'est un annuaire LDAP dont il existe plusieurs implémentation sous Linux depuis fort longtemps.

Pour les outils d'administrations graphique, ils sont "peaufinés" depuis plus de 20 ans, mais on été créés avant les années 2000, en moins 5 ans si on suit la chronologie des "avancées techniques Microsoft".

L'avantage qu'à Linux est que tous les outils d'administrations (en ligne de commande) et/ou fichiers de configurations existent. Sur Windows, ce n'est pas toujours le cas, d'où la complexité de la chose.

Evidement, faire aussi bien, même mieux que ce qu'à fait Microsoft, ne peut pas se faire en quelques semaines. En revanche, en moins de 5 ans pour une équipe de 10 personnes je n'ai aucun doutes.
Mes doutes sont plutôt dans la lucidité des décideurs, qui préfèrent ne pas "risquer" 5 millions d'euros pour en économiser des centaines.

Quelles solutions libres existent pour remplacer Active Directory et des outils Windows d'administration dans son ensemble ?

A mon avis quand on commence à prendre le problème par là, on se trompe de chemin.
L'administration dépense de millions dans les outils Microsoft, avec une petite partie de ce budget on peut créer tous les outils du parfait petit administrateur système qui veut "tout gérer en 2 clics".
Ce n'est pas un problème technique, n'importe quelle petite équipe d'ingénieur est capable de créer une solution bien meilleure que ce que peut proposer Microsoft. C'est politique.

Vous remarquerez que c'est d'ailleurs la manière dont ceux qui ont intérêts à ce que rien ne change qui engagent le débat sur l'existence ou non d'alternatives, en se passant bien d'évoquer l'option de créer une alternative.

Ce n'est plus gratuit, voici les tarifs officiels : 1ère de demande : 30 € HT (36 € TTC)

Voir https://www.afnil.org/tarification/ pour les détails.

D'un autre côté, laisser programmer des web developers agiles frontend/backend [TM] en C, en sachant pertinemment qu'ils n'auront ni l'envie ni la contrainte d'écrire une suite de tests… c'est très risqué, voir dangereux ;)

Passer de C à Javascript c'est surtout encore consommer utiliser intelligemment plus de ressource processeur et de mémoire vive.
Effectivement, Rust aurait été un meilleur choix risqué. Mais il y a aussi l'option d'auditer le code C et d'écrire une suite de test complète.

Thunderbird fait partie de ces logiciels qui se dégradent lentement mais surement avec le temps qui migrent vers les technologies du web 3.0 . Pour gérer mes 4 boîtes emails, il s'accapare n'utilise admirablement qu' un unique gigaoctet de mémoire vive, a des lenteurs et crashs aléatoires incite son utilisateur a le fermer régulièrement dans un soucis d'optimisation des ressources.

L'équipe de développement a clairement pris le chemin de la réécriture totale en JavaScript, une route sans retour au pays du typage dynamique et autres joyeuseté qu'il est bon de fuir quand on cherche à faire un logiciel performant et fiable des meilleurs logiciels actuels.

Heureusement que l'on a de jolies icônes maintenant, merci la MZLA Technologies Corporation.

Ça fait longtemps d'ailleurs qu'on n'a pas eu de dépêche sur OpenConcerto.

Je me disais la même chose :)
On va bientôt en reparler avec la gestion de lot, de numéro de série, DLCU, DLUO…

Je vois pas en quoi.

Et bien, je t'invite à te renseigner sur le fonctionnement d'un serveur web, de la "mise en route" d'une connexion TLS.
La team "on est pas à 10Mo près et à 100ms près" me déprime.

(NDLR : mais bon, on est maintenant dans un monde de croyances assez folles, ou l'optimum c'est du node.js en docker. Et comme c'est à la mode, les biais cognitifs font que toutes réalités informatiques relatés par ceux qui connaissent l'assembleur, les vrais performances du matériel et les langages dits "bas niveau" par les ignares sont ignorées.)

Je vous conseille la lecture des commentaires de Lyon Mag, c'est ce que l'on fait de mieux en terme de dissonance cognitive et biais cognitifs concernant les logiciels libres.

DynFi Firewall, le premier parefeu Open Source français

ou plutôt "la version traduite en francais de OPNSense".

L'affirmation ci-dessus aurait un sens si DynFi n'utilisait pas le parefeu "pf", le reste n'étant qu'une interface évoluée de configuration de "pf" et du système FreeBSD… qui n'ont rien de français.

Bref… demain je traduis TensorFlow et l'autoproclame la première plateforme d'apprentissage automatique?

Le dépôt, nous l'avons déjà : https://code.openconcerto.org

Le temps qui nous manque est passé à s'occuper de nos clients, on a juste besoin de plus d'utilisateurs qui passent le pas du cloud ou prennent un contrat de maintenance afin de nous donner de l'air financièrement.

La version web arrive prochainement.
Avec elle, un tas de changement et aussi une API (json rpc).

Il est vrai que le temps manque, nous avons un carnet de commande rempli à plus de 6 mois.

C'est quoi le concept de "souplesse technique"?

On fait ce qu'on peut avec nos petits moyens (par rapport à Odoo).

Si vous voulez nous aider, profitez du forum d'OpenConcerto pour faire vos retours pour atteindre "la perfection".
On ne vous en voudra pas non plus si plus dépensez quelques euros dans l'histoire ;)

Belle réussite et chapeau d'avoir su gérer une croissance si forte!

Bonjour,

Les immobilisations, oui c'est prévu, cela fait partie de la feuille de route présentée lors du live YouTube (lien dans la dépêche).

Les calculs des immobilisations n'étant pas très compliqués, beaucoup d'utilisateurs se satisfont d'un calcul sur tableur et de la saisie manuelle des écritures associées.