✓ Travailler en mode projet
✓ Mettre à disposition des utilisateurs un service informatique
L’entreprise ayant besoin temporairement d’une application plus flexible pour gérer ses stocks, j’ai eu l’opportunité de créer une application Appsheet pour répondre à ce besoin
But de l’outil
- Gestion d’une base d’article, avec les quantités en stock, la valeur des stock etc …
- Gestion de fournisseurs chez lesquels on peut commander les articles de la base
- Possibilité de faire une réception depuis le fournisseur, cela crée un enregistrement dans l’application, et un nouveau lot pour chaque article
- Possibilité de faire une sortie : on peut sortir X unité d’un lot, ce qui se répercute sur le stock. Chaque sortie est associée à un service, ce qui est utile pour des raisons comptables
- Il est possible de faire un inventaire. C’est de loin la partie de l’application la plus retors
Sur l’outil Appsheet / le no code en général
Appsheet propose de créer une application se reposant sur une base de donnée sous forme de feuille de calcul (d’où le nom).
Le prototypage est fulgurant par rapport au développement Android en Kotlin/C++ traditionnel. On arrive ainsi assez vite à déployer une application fonctionnelle.
Les problèmes viennent lorsque l’on cherche à implémenter des fonctionnalités plus avancées. On doit alors se livrer à des exercices de contorsionnisme là où seulement quelques lignes de codes auraient suffit. En quelques mots : c’est un outil qui “scale” très mal. Il est sage de se cantonner à des applications assez sommaires. Il en est de même avec le coût qui augmente proportionnellement au nombre d’utilisateurs, jusqu’à atteindre des tarifs prohibitifs là où une application codée aurait un coût fixe. On devient aussi tributaire de l’éditeur de l’outil, en l’occurrence Google ici. Si un tel outil est utilisé en production et qu’il est soudainement discontinué, une catastrophe s’en suivrait. Il y a une perte de contrôle très importante sur le produit par rapport au développement classique.