OutSystems: Pourquoi Nous Faut-Il Toujours Plus De Logiciels ?
Pourquoi nous faut-il toujours plus de logiciels ?
Un coup d’œil sur n’importe quel bureau d’ordinateur ou écran de smartphone en dit long : ils sont remplis d’applications. Certaines sont utilisées tous les jours, d’autres une seule fois, mais nous les laissons sur le système par facilité. Faut-il donc développer toujours plus de logiciels ? La plateforme informatique que nous utilisons n’a-t-elle pas assez de flexibilité et d’options personnalisables pour nous donner la bonne fonctionnalité ? Le fait est qu’avec l’évolution du monde et la transformation numérique, le besoin de plus de logiciels reste important. Pour mener cela à bien, il est judicieux d’examiner le cycle de vie du développement logiciel.
Maniable et flexible
L’appel à de nouvelles applications découle de la nécessité de maniabilité et de flexibilité. Les organisations doivent s’adapter aux évolutions du monde qui les entoure. Pour reprendre les termes du trendwatcher Peter Hinssen, nous sommes à l’ère du « Never Normal ». À la croisée de l’économie, de la politique et de la sociologie, la dynamique est grande et en tant qu’organisation, vous faites face au défi constant d’y répondre. Il s’agit parfois de chaînes d’approvisionnement perturbées par les tensions internationales. Mais vous êtes également confronté à l’évolution des souhaits des consommateurs, notamment en raison de l’inflation et des prix élevés de l’énergie. Ces changements engendrent des besoins de soutien aux nouvelles technologies de l’information sous la forme d’applications et de services de données. Ils ont une chose en commun : l’agilité. Il faut pouvoir disposer rapidement de nouvelles solutions, les développer et les adapter rapidement.
Systèmes Legacy
Même s’il y a toujours une motivation à mettre en œuvre de nouvelles solutions IT, nous devrons inévitablement conserver certains systèmes Legacy (ils fonctionnent en effet encore, il s’agit donc d’un héritage). Nous le constatons surtout dans des secteurs tels que les services financiers. Dans ce contexte, vous devrez bel et bien tenir compte du fait que les systèmes fondamentaux ont généralement été livrés sous forme standard, puis adaptés sur mesure. La maintenance et la sécurité sont très complexes. Mais c’est gérable en utilisant la technologie de développement low-code.
Vous devez donc faire quelque chose pour pouvoir développer rapidement des applications et des solutions sur mesure, et pour que tout reste sûr et gérable. La question est ensuite la suivante : comment décider quelles applications il faut réécrire ou reconfigurer et migrer d’une part, et lesquelles il faut conserver d’autre part ? Si nous examinons cela du point de vue de la fonctionnalité, il y aura toujours un certain nombre de systèmes dans le back-end d’une organisation qui sont une forme d’héritage. Ce ne sont certainement pas des applications qui ont perdu de leur valeur ; elles font toujours le travail auquel elles étaient destinées en premier lieu. Le défi est que l’application soit contrainte, en termes de modalité et de forme, d’évoluer en plateformes, protocoles et normes modernes. L’autre problème, non négligeable, avec les systèmes Legacy réside dans les compétences et le transfert de connaissances nécessaires pour comprendre, mettre à jour et entretenir un système souvent obsolète. Ceci est d’autant plus important que le marché de l’emploi connaît une forte pénurie.
L’évolution logicielle
Lorsque la plateforme sous-jacente sur laquelle fonctionne une application change, cela contraint généralement à un niveau plus élevé de refactoring, de reformulation et de migration. Ce n’est pas totalement une mauvaise nouvelle. Ce processus offre aux organisations l’occasion d’optimiser cette application à ce moment-là. Les Lois de Lehman sur l’évolution des logiciels stipulent qu’une fois que nous donnons quelque chose à un utilisateur, ses attentes changent et la complexité logicielle d’un système ne cessera d’augmenter pendant sa durée de vie.
Cette réalité rend solide l’argument en faveur d’une évolution logicielle à chaque niveau. Nous entendons par là que même quand le logiciel fait son travail, il sera soumis à une complexité croissante. Cela signifie que nous devrons au final faire évoluer cette application, même si elle fonctionne bien. Pour boucler la boucle : nous pouvons toujours conserver la fonctionnalité héritée, mais l’application proprement dite doit à terme être convertie en une plateforme plus moderne.
La conclusion est que les organisations dans le cycle de vie du logiciel ne doivent pas attendre le signe d’un fournisseur que les applications arrivent en « fin de vie ». Elles devront continuellement faire des efforts pour réduire la complexité et garantir la fonctionnalité des applications. Et si l’on suit le mode de pensée de Peter Hinssen, selon lequel nous devons continuer à vivre à une époque où rien n’est normal, il faut surveiller constamment les fonctionnalités dont on a besoin. Maintenant que nous utilisons de plus en plus de plateformes low-code et no-code dans le cadre du développement logiciel, vous avez l’occasion, en tant qu’organisation, d’aborder la question de manière proactive.
À propos d’OutSystems
OutSystems a été fondée en 2001 avec pour mission de donner à chaque organisation le pouvoir d’innover grâce au logiciel. La plateforme low-code haute performance d’OutSystems offre aux leaders technologiques et aux développeurs les outils nécessaires pour créer et déployer rapidement leurs propres applications critiques. Le réseau de l’entreprise compte plus de 600 000 membres de la communauté, plus de 400 partenaires et des clients actifs dans 87 pays et dans 22 secteurs. OutSystems est « The #1 Low-Code Platform® » et un leader reconnu par les analystes, les responsables informatiques, les chefs d’entreprise et les développeurs du monde entier. Certaines des marques les plus connues utilisent OutSystems pour transformer leurs grandes idées en logiciels qui font avancer leur entreprise, leur personnel et le monde. Pour en savoir plus, consultez le site www.outsystems.com .
