Comment savoir s’il faut passer d’un outil low-code à une solution plus robuste?

[Ronald.C]

Salut tout le monde, je me tourne vers vous parce que je suis un peu perdu sur un point précis. Je travaille sur un outil interne pour mon équipe avec un constructeur visuel assez basique, et je me demande si je devrais persévérer avec ou si je passe le cap vers une solution plus sérieuse. Le truc, c’est que j’ai l’impression de buter sur les mêmes limites à chaque fois, surtout pour connecter des données entre deux apps. Vous avez déjà ressenti ce plafond de verre avec un outil low-code ? Comment vous avez su qu’il fallait changer d’approche ?

[AvaT]

Pour moi le vrai plafond c est quand les liaisons entre apps deviennent fragiles et couteuses en maintenance. Avec un outil low code tu te retrouves souvent a écrire des bricolages pour faire passer des donnees d un systeme a l autre et un oubli ou un changement de schema te tombe dessus sans prevenir. Si tu envisages une alternative regarde la latence des appels la robustesse des mappings les journaux d erreurs et la facilite d ajouter des connectors ou des API. Si a chaque modification il faut tout reecrire c est signe qu il faut passer a une approche plus robuste

[Charles61]

Franchement ca énerve. Je me suis battu avec des flux qui paraissent simples sur le papier mais qui explosent des que les donnees bougent. Le sentiment que tu dois bricoler au lieu d avancer est epuisant. Si tu veux je crois que le vrai choix depend de ce que tu attends de l outil en termes de serialization des donnees et de tracabilite sans ca le curseur reste bloque

[Aurora_M]

Est ce que le probleme nest pas plutot la maniere dont on pose le besoin Peut etre que le cap vers une solution plus serieuse est une reponse a une mauvaise definition des besoins et non une limitation technique Un outil low code peut suffire si ton modele de donnees est stable et si tu as un vrai plan d orchestration Sinon il faut envisager du code pers ou une plateforme orientee API first

[Grace.M]

Si je reformule le probleme ce n est pas la question faut il changer d outil mais comment assurer une connexion fiable entre deux apps sans perdre de coherence des donnees Le choix se joue entre un connecteur simple une normalisation des donnees et une governance adapte a l usage Dans ce cadre le mot cle low code peut rester un facilitateur ou un frein selon le niveau d abstraction voulu

[DanielIT]

Teste avec un proof of concept cible une passerelle de donnees entre deux apps mesure la latence et les erreurs regarde le cout sur six mois et vois si tu as des limites qui bougent ou qui cassent trop souvent sinon passe a une stack plus robuste

[Luke14]

J ai vu des equipes s embourber dans l idee que plus ce sera simple mieux ce sera Une culture qui choisit le low code pour tout peut se diluer dans des habitudes de rapidite sans plan de long terme Du cote des lecteurs et des utilisateurs les attentes se brouillent certains veulent juste que ca marche d autres veulent des solutions qui racontent une histoire autour du flux de donnees peut etre que le vrai test n est pas la puissance technique mais la maniere dont le produit supporte l evolution des besoins et la tolerance au changement en particulier pour les personnages du metier qui s appuient sur ces donnees