Rapport : Couverture de l’API Dolibarr par l’Application

Ce document détaille la couverture de l’API REST standard de Dolibarr par l’application iOS actuelle.

Ce rapport a été généré en comparant la documentation Swagger de l’API REST de Dolibarr avec l’arborescence des modules (features) dans l’application.

1. Modules parfaitement (ou largement) intégrés

Les entités (endpoints) suivantes de l’API Dolibarr ont un module dédié et implémenté dans l’application :

(Note: Des modules additionnels comme Assets, Holidays, Loans, Recruitment, Salaries sont également implémentés dans l’application).

2. Modules exposés par l’API Dolibarr mais NON présents dans l’Application

Les entités suivantes sont disponibles via l’API REST standard de Dolibarr, mais n’ont pas d’écran dédié ou de gestion complète dans l’application iOS actuelle.

• categories : Gestion des tags/catégories (L’API permet de lister, créer des catégories. Actuellement, l’app utilise parfois les catégories pour l’affichage, mais n’offre pas d’interface complète de gestion des catégories en soi).
• eventattendees : Gestion des participants aux événements (souvent lié à l’Agenda, mais pas exposé en gestion autonome dans l’app).
• memberstypes : Gestion des types d’adhérents (configuration du module Adhérents).
• mos (Manufacturing Orders / Ordres de Fabrication) : L’application gère les BOM (Nomenclatures) mais pas les Ordres de Fabrication.
• objectlinks : Gestion technique des liens entre les différents objets Dolibarr.
• setup : Configuration globale de Dolibarr (Récupération des infos sociétés, dictionnaires, etc. L’app s’en sert en lecture pour la config, mais on ne peut pas paramétrer Dolibarr depuis l’app).
• stockmovements : Mouvements de stock (L’app gère les entrepôts, mais l’interface pour visualiser ou effectuer manuellement des mouvements de stock via cet endpoint direct n’est pas une “Feature” principale isolée).
• subscriptions : Abonnements (Cotisations liées aux adhérents, souvent gérées indirectement, mais pas de module “Abonnements” global).
• supplierproposals : Demandes de prix fournisseurs.
• users : Gestion des utilisateurs (Création, modification des utilisateurs système Dolibarr).
• workstations : Postes de travail (lié à la production/fabrication MRP).

3. Pourquoi l’application ne couvre pas “100%” de Dolibarr ?

1. L’API de Dolibarr ne couvre pas 100% de Dolibarr : Dolibarr est un ERP gigantesque développé historiquement en PHP. L’API REST a été ajoutée “récemment” et ne couvre qu’une partie (la plus utilisée) du logiciel. Par exemple, la Comptabilité avancée, les Taxes/TVA, le Point de Vente (POS), la gestion des exports, et une multitude de paramètres et dictionnaires ne sont pas (ou peu) exposés par l’API REST officielle.

2. Choix ergonomiques (Mobile vs Desktop) : Une application mobile n’a pas pour vocation de remplacer l’interface web pour des tâches d’administration lourdes ou de paramétrage (module setup, module users, configuration comptable). L’application se concentre sur l’usage “quotidien” et “en mobilité” (CRM, Ventes, Projets, RH, etc.).

3. Complexité de certains modules : Les modules de production (MRP : mos, workstations) ou de demandes de prix fournisseurs (supplierproposals) sont des cas d’usage plus spécifiques qui n’ont pas encore été priorisés pour la vue mobile.

Conclusion

L’application couvre l’écrasante majorité des cas d’usages quotidiens permis par l’API REST de Dolibarr (plus de 80% des endpoints de gestion courante sont implémentés).

Si vous détectez le besoin d’interagir avec l’un des points manquants mentionnés dans la section 2 (ex: Demandes de prix fournisseurs, Ordres de fabrication, Mouvements de stock détaillés), ces fonctionnalités peuvent être ajoutées dans les prochaines itérations de développement de l’application !