Les applications internes, l’enfant (souvent) négligé du développement logiciel – SD Times
Les outils internes sont des applications logicielles personnalisées conçues pour les utilisateurs internes d’une organisation. Ces applications ont pour la plupart des fonctionnalités CRUD et sont conçues par des ingénieurs pour des utilisateurs tels que les ventes, l’assistance, les finances, les ressources humaines, l’ingénierie et tous les autres. Par exemple, voici un exemple d’un outil que nous avons créé pour interagir avec nos utilisateurs à l’aide de Mixpanel, Reply et ActiveCampaign. Chaque entreprise dispose d’outils internes pour répondre à ses besoins spécifiques et à ses processus uniques. Comme Michael Novati sur Facebook écrit tout en parlant d’un tableau de bord de communication d’entreprise qu’il était en train de créer, Weve a appris que des outils de communication d’entreprise efficaces doivent être conçus spécifiquement pour nos employés, car notre base d’employés et nos besoins commerciaux sont très uniques.
Effort d’ingénierie
Les outils internes finissent par prendre une quantité décente de temps d’ingénierie. Au fil du temps, ces outils nécessitent plus de fonctionnalités, ou des outils supplémentaires sont construits (ce qui est toujours le cas). Cela inclut également la mise à l’échelle et le suivi des outils obsolètes. Cela finit par devenir un contributeur non négligeable à la charge de travail d’ingénierie.
L’approche la plus courante pour créer des outils internes consiste à utiliser un framework open source comme React ou Angular ou Flutter. Ce sont des frameworks puissants, mais leur maintenance nécessite beaucoup de travail. Ainsi, chaque nouvel outil est créé à partir de zéro. Comme l’écrit Novati dans le même article de blog, Un problème que nous avons chez Facebook est qu’il y a tellement de demandes d’outils internes personnalisés (de la part d’ingénieurs et de non-ingénieurs) que nos ingénieurs d’outils internes ont du mal à suivre. Il explique ensuite comment Facebook a créé des widgets réutilisables ou des composants d’interface utilisateur afin que les utilisateurs puissent créer des outils plus rapidement. Maintenant, imaginez faire cela si vous ne faites pas partie d’une entreprise comme Facebook avec tout son personnel technique.
Les outils internes, comme tout autre logiciel, nécessitent une collaboration et une rétroaction entre les constructeurs et les utilisateurs. Ces commentaires se retrouvent souvent dans plusieurs endroits comme Slack, les e-mails, les documents Word. L’utilisateur interne et l’ingénieur finissent ensemble par revêtir la casquette de chef de produit et finissent par faire des allers-retours pour essayer de définir l’application.
Les outils internes n’ont souvent pas le meilleur UX. Il y a plusieurs raisons à cela. Certains sont liés à la bande passante, d’autres à l’expertise. En outre, cela peut être dû au fait que les outils internes peuvent ne pas avoir la priorité que les applications destinées aux consommateurs obtiennent. De plus, il n’y a pratiquement pas de bande passante de conception attribuée à ces outils, car la plupart des concepteurs souhaitent travailler sur des applications destinées aux consommateurs.
Comme Hannah Mari-Kris, chef de produit chez le géant néo-bancaire Monese, reflète, Les parties les plus délicates sont généralement lorsqu’une vue particulière doit répondre aux besoins de plusieurs équipes. En effet, les outils internes traitent souvent de nombreuses données sensibles et, en tant que propriétaire de l’outil, vous voulez être très sûr de qui obtient quel type d’accès, qu’il s’agisse d’un accès en écriture ou en lecture.
Low code comme alternative ?
Les frameworks ou plates-formes low code offrent aujourd’hui une bonne alternative à la création d’applications internes.
Ces frameworks aident à réduire la quantité d’efforts d’ingénierie requis pour créer des outils internes grâce à une liste réutilisable et toujours croissante de composants d’interface utilisateur, de connecteurs ou d’intégrations natives aux sources de données, de fonctionnalités collaboratives et d’une documentation complète.
Ainsi, l’équipe d’ingénierie crée plusieurs applications personnalisées sur une seule plate-forme sans avoir à gérer plusieurs applications React ou Angular.
Voici comment vous pouvez choisir un bon framework low code
Vérifiez si ces plates-formes incluent des fonctionnalités conviviales pour les développeurs, telles qu’un bon éditeur de code avec des capacités de linting, ainsi qu’un contrôle de version et une synchronisation Git, ou une expérience de type IDE dans l’éditeur de code avec un débogueur natif.
La collaboration est un autre facteur important à considérer. L’une de nos fonctionnalités les plus demandées a été un système de commentaires en temps réel semblable à ce que vous voyez dans Figma, qui peut aider à relayer les commentaires entre les développeurs ainsi qu’entre les équipes d’utilisateurs finaux, raccourcissant ainsi le cycle de développement.
Vérifiez si le framework low code est livré avec des fonctionnalités de contrôle d’accès robustes et granulaires, car cela devient dans la plupart des cas un facteur décisif lors de l’évaluation de ces outils pour une utilisation dans les entreprises.
Souvent, la plate-forme low code remplace un framework open source comme React. Heureusement, il existe aujourd’hui des frameworks open source low code. Les frameworks open source low code donnent à votre équipe le pouvoir de contrôler la vitesse de votre développement en signalant les bogues et en faisant réparer un membre de la communauté, sinon les mainteneurs. Ou, s’il y a une fonctionnalité critique que vous voulez qui n’est pas encore sur la feuille de route, vous pouvez simplement la construire ou contribuer au code source principal ou contacter les responsables.
Vérifiez si la plate-forme low code que vous utilisez a une version auto-hébergée. Cela devient plus important lorsque vous traitez des données sensibles et que vous souhaitez ajouter une couche de sécurité supplémentaire en hébergeant vos applications sur vos propres serveurs.