Des solutions "low code" ou "no code" poussées au-delà de leurs limites
L'un des inconvénients majeurs des solutions "low code" ou "no code" est que ces outils sont souvent poussés bien au-delà de leurs limites. La nature même des solutions "low code" ou "no code" signifie qu'elles ont des limites intégrées pour tenir compte de la manière dont elles sont construites. Par exemple, ces types de solutions ont des difficultés à gérer de grands ensembles de données ou des règles commerciales complexes.
Pourtant, de nombreuses personnes choisissent d'utiliser des solutions à code réduit pour ces constructions. Ce faisant, on repousse les limites et on contraint le système à code bas. Si, par exemple, vous traitez de grandes quantités de données, cela peut poser problème. Si de nombreux automatismes sont exécutés lorsqu'un type particulier de données est ajouté ou modifié, ou si des calculs ou des traitements très complexes doivent être effectués, les limites du système peuvent être mises à rude épreuve.
Les limites du système peuvent être mises à rude épreuve. Si vous devez gérer un grand nombre d'utilisateurs simultanés, la complexité de la solution finale s'en trouve également accrue. Dans ce cas, vous surchargez la solution "low code". Elle n'a pas été conçue pour gérer un projet d'une telle ampleur. Il serait plus facile d'opter pour une solution personnalisée ou hybride.
Le choix du moment et de la manière d'intégrer une solution "low code" ou "no code" doit tenir compte de ces limites. Il arrive que des solutions hybrides ou entièrement personnalisées permettent réellement de gagner du temps de développement et d'améliorer le résultat final.
Gérer ces solutions après le départ du développeur
Les solutions "low code", comme nous l'avons mentionné, sont excellentes pour les projets de petite et moyenne taille. Mais beaucoup de gens tombent dans le piège de penser Pourquoi faire appel à un développeur alors que je peux faire appel à quelqu'un qui connaît bien le système ? Vous économisez de l'argent, vous utilisez quelqu'un de l'entreprise, où est le problème ?
Bien souvent, l'utilisation ou l'habilitation d'un développeur citoyen (une personne interne qui connaît bien le système) pour construire ses propres solutions est une excellente façon de répondre rapidement aux besoins de l'entreprise. Toutefois, une gouvernance et une formation adéquates sont essentielles. Lorsque les développeurs citoyens utilisent leur compte personnel pour construire le système et qu'il n'y a pas de gestion adéquate du cycle de vie de l'application. Lorsque cet employé part, vous êtes coincé.
Vous devez sécuriser le compte de cet employé parce qu'il ne peut plus avoir d'accès organisationnel, mais il a utilisé son compte pour construire le système. Vos processus d'entreprise sont liés au compte d'un employé qui doit être désactivé pour des raisons de sécurité.
Les développeurs citoyens n'ont souvent pas l'œil pour la gestion du cycle de vie, l'architecture ou la conception des systèmes sous-jacents. Dans le pire des cas, vous devrez tout reconstruire après le départ de cette personne.
Quand utiliser une solution "low code" ou "no code" et quand envisager un code personnalisé ?
La question de savoir s'il faut utiliser une solution "low code" ou engager un développeur externe est liée à l'ampleur et à la complexité de la construction requise. Comme nous l'avons mentionné précédemment, les grands ensembles de données constituent l'un des principaux pièges. En fonction de l'intégration, des ensembles de données aussi petits que 2000 éléments peuvent commencer à nécessiter des considérations supplémentaires.
Dans certains cas, vous vous rendrez compte que quelque chose existe déjà dans votre source de données. Vous ne serez pas en mesure de le rechercher et de le ramener parce que vous ne pouvez pas retourner suffisamment d'éléments. Vous pouvez aussi risquer que votre solution "à faible code" ne le soit plus pour contourner les limites.
Vous finissez par faire plus de travail pour contourner les limites d'une solution "low code" ou "no code", ce qui va ralentir l'application, coûter plus de temps de développement et nécessiter plus de tests.
Vous devez également tenir compte des performances lorsque vous décidez d'utiliser une solution "low code" ou "no code" ou de faire appel à un développeur. Dans PowerApps, si vous avez affaire à une variété de sources de données et à une interface utilisateur complexe, cela a un impact sur la réactivité et peut ralentir votre solution. Avec une création personnalisée, vous pouvez tout rationaliser pour accélérer l'exécution.
Dans Power Automate, lorsqu'il y a beaucoup de traitements en cours, comme la mise à jour de champs, vous mettez en boucle différents éléments et passez au peigne fin de grandes quantités de données provenant de différents endroits. Cela peut entraîner des ralentissements, car Power Automate a des limites quant au nombre d'actions recommandées par flux.
Une fois ce seuil dépassé, Microsoft peut suspendre votre flux. Désormais, une partie potentiellement critique de votre processus d'entreprise ne fonctionne plus, et vous n'avez vraiment pas de chance.
Les solutions "Low Code/No Code" sont plus rapides à mettre en place (ou le sont-elles ?)
On pense souvent à tort que les solutions à faible codage sont plus rapides à mettre en place. Les développeurs disposent de plusieurs outils qui peuvent être utilisés pour un développement rapide. Pourtant, certaines personnes se sont convaincues qu'elles devaient utiliser une solution à code réduit.
Lorsque la construction est plus complexe, les solutions à code personnalisé peuvent souvent être construites plus rapidement que les solutions à code bas ou sans code. Vous courez également le risque que la solution "low code" donne de mauvais résultats parce que vous êtes entré dans un territoire très complexe.
La solution "low code" est idéale pour les développements simples et de petite taille. Au-delà, vous risquez de vous heurter à des difficultés imprévues. Les solutions personnalisées n'ont pas le même type de contraintes et de restrictions, ce qui les rend globalement plus flexibles.
En outre, il arrive souvent que des personnes utilisent la solution "low code" et décident ensuite d'ajouter d'autres modules que ceux initialement prévus. Ce que vous pensiez être une solution simple s'avère être plus nuancé et plus complexe que prévu. La construction devient plus lente et le risque d'une mauvaise performance de l'application s'accroît.
Les avantages des solutions "Low Code/No Code
En définitive, ces outils sont extraordinaires. Le but de ce blog n'est pas de vous en détourner complètement. Vous avez besoin de créer un flux pour planifier quelque chose qui vérifie les nouvelles entrées dans une base de données pour certaines conditions, très bien. Utilisez ces outils. Mais n'oubliez pas qu'ils ont des limites. Connaître ces limites et savoir quand utiliser des solutions "low code" ou "no code", une solution personnalisée ou hybride est la clé du succès.
Il est essentiel de comprendre le point de transition entre la solution "low code/no code" et la solution personnalisée ou hybride. C'est là que les consultants, comme nous chez Improving, peuvent aider. Car il y a des conséquences à long terme si ces outils ne sont pas utilisés correctement. Ne tombez pas dans ce piège.
Si vous êtes à la recherche d'une application personnalisée, contactez-nous dès aujourd'hui !
