La pérennité de tes outils web n'est pas comme tu aimerais #13
/** Commentaires #13 — */

La pérennité de tes outils web n'est pas comme tu aimerais

La pérennité de ton projet dans ton entreprise n'est reliée qu'aux technologies choisies et à la structure du projet, mais le temps et l'argent que tu peux investir dans la création et la maintenance de celui-ci.

Selon moi, les projets sur les internets ;) sont plus comparables à l’adoption d’un animal qu’à l’achat d’un équipement pour la consommation. Même si c’est numérique.

Je ne t’apprends pas qu’on transpose nos comportements d’acheteurs d’objets physiques dans le web.

Il faut toujours alimenter notre écosystème sur le web pour qu’il soit actif et qu’il exécute ce qu’on lui a demandé grâce à notre implémentation.

Et on le nourrit en payant des services, mais surtout en planifiant la maintenance et les mises à jour.

Heureusement, on est en mesure d’automatiser beaucoup d’éléments. C’est principalement pour ces automatisations que tu payes ton hébergeur ou ton registraire de domaines.

La pérennité de tes outils web n’est pas comme tu aimerais.

On s’adapte toujours. Sauf que j’ai l’impression qu’on ressent de la déception quand même, surtout lorsqu’on met à jour une application récemment développée.

La question de la pérennité sur le web, c’est presque une antithèse ou un idéal. On tend vers ça, mais on doit quand même investir du temps pour rendre pérenne notre écosystème numérique.

Car c’est une grappe de manœuvres qu’il faut mettre en place pour limiter les coûts de maintenance.

Alors, la pérennité d’un outil web doit être définie et planifiée avec tout son cycle de vie et selon les humains impliqués. De la prévention et de planification à la mise en ligne et la maintenance.

Comment rend-on pérenne un animal web ?

Je ne parlerai pas de rétention du personnel, mais plus du cycle d’un projet et les rôles nécessaires pour améliorer la pérennité d’un projet.

Et les projets web, on commence très tôt dans notre vie d’entrepreneur à faire.

Même si tu n’évolues pas sur le web activement, tu es dépendant de la pérennité de pleins outils.

Par exemple tu dois avoir un service pour recevoir et envoyer des courriels, qui ont besoin de ton domaine. Sans compter toute ton administration, où tu dois facturer ton offre à tes clients et gérer ton calendrier.

Ajoute à tout ça ta communication, ta gestion avec tes clients et toutes tes idées grandioses pour améliorer ton entreprise.

Je ne veux pas te donner le vertige.

Il faut juste prendre en compte qu’il faut s’assurer que tous nos outils web doivent être maintenus par des humains. Qu’il soit à l’interne ou dans une compagnie tiers.

La planification de son projet passe nécessairement par l’équipe qui le développe et qu’il le maintient pour qu’il soit pérenne.

La pérennité lors du développement

Il faut commencer à y penser avant la conception du projet.

En amont du développement et de l’architecture, il faut penser aux besoins qu’on veut combler avec le projet.

De façon entrepreneuriale ou technique, on doit être en mesure de décrire notre besoin clairement avec les observations qui rendront le projet bénéfique.

Il faut savoir quoi faire, avant de savoir comment le faire.

Le choix de la main-d’œuvre

Lorsqu’on est en mesure de décrire notre projet clairement. Il faut déterminer si on est capable à l’interne d’accomplir le projet avec notre expertise et dans le temps avec notre charge de travail.

Est-ce que nos techniques habituelles fonctionnent bien pour obtenir les résultats escomptés.

Sans dicter l’architecture du produit, il faut évaluer l’équipe idéale et la grappe technologique la plus propice à soutenir notre projet.

Et idéalement avec des coûts optimisés.

L’équipe avant la technologie

Dans le web, il y a plusieurs structures et langages qui permettent d’accomplir des résultats satisfaisants et comparables.

Lorsqu’il vient le temps de comparer deux solutions différences. Les collaborateurs et leurs expertises sont l’élément central qui détermine la décision.

Et c’est dès la planification et le choix de l’équipe que l’on doit penser à la maintenance : mise à jour, suivi, surveillance des performances, etc.

Le plus grand risque d’écroulement pour le projet réside pendant la période de vie en production.

Autant parce qu’il faut investir du temps, des efforts, de l’argent que pour l’adapter en ajoutant des fonctionnalités et du contenu.

Autant que c’est là qu’on teste pour vrai notre réalité. Et C’est là qu’il faut être en mesure de s’adapter.

Selon moi, c’est toujours plus agréable de faire une longue route en étant bien préparé avec des gens qu’on a sélectionnés pour ça.

La pérennité grâce à l’architecture

Je pense autant à l’architecture technologique (serveurs, SaaS, FaaS, etc.) qu’à l’architecture du code.

Est-ce qu’on loue l’infrastructure et qui gère le serveur ?

Est-ce qu’on utilise un Framework et quel est le processus de mise à jour.

Quel(s) librairie(s) aurait-on besoin pour accomplir notre fonctionnalité principale ?

C’est la jungle et quasiment impossible de trouver une réponse claire ou une assurance pérennité. Il faut établir un processus de décision le plus scientifique possible.

Regarder l’historique des versions, le type de version qui on été fait par le passer (majeure vs mineurs, fréquences).

Quelle est la grosseur de la communauté.

Quel est l’état de la documentation.

Quel est le nombre de commentaires ouverts sur leur répertoire.

Est-ce qu’un outil de monitoring de sécurité a une opinion déjà sur la librairie.

Est-ce que les fonctionnalités sont trop large pour nos besoins ?

Avec l’open source, il faut toujours se préparer à devoir maintenir une branche à l’interne. Advenant que les développeurs ne le soutiennent plus.

C’est là où les SAAS/FAAS, sortent du lot grâce à une structure qui subvient au maintien du service.

Ce n’est pas sans risque, car une compagnie peut fermer et là on n’aura plus accès aux fonctionnalités.

Prévoir l’imprévisible.

La pérennité est facilitée grâce à l’agilité de la structure et du processus.

L’implémentation et les ajustements en cours de travail et de tests sont essentiels, autant que l’architecture logicielle.

Il faut se prévoir des outils et de l’espace pour accomplir des manœuvres que l’on ne connaît pas encore.

Il faut que l’architecture du logiciel permettre une modularité qui facilite l’ajout de fonctionnalités.

Par exemple ajouter un API prêt pour des services comme zapier/make qui permettent de connecter deux outils ensemble dans une interface en lowcode.

Tout ça afin de connecter votre projet à votre écosystème, maintenant ou plus tard. Toujours en gardant en tête la maintenance et les coûts.

L’expérience utilisateur

C’est essentiel pour l’implantation de l’outil dans vos processus plus que pour la pérennité.

Mais de façon holistique tout aussi importante pour la pérennité.

Qui mettrait de l’argent et du temps dans le maintien d’un outil qu’on utilise peu ?

Et c’est tellement triste lorsqu’un projet meurt, parce qu’on n’a pas pensé aux utilisateurs finaux. Tout ce temps pour un projet qui meurt après 2 ans.

Au moins tu auras décelé des points centraux à améliorer dans vos processus.

Prévoyez des outils adaptés à votre équipe ou préparez-les pour que votre équipe puisse les prendre en main, selon leur expertise.

C’est super important de désigner votre outil pour vos utilisateurs finaux, d’adapter le projet à vos processus ou l’inverse. Tout dépendant de ce qui est le plus efficace.

L’open source et la pérennité

C’est à double tranchant, on peut trouver une solution parfaite ou construire une solution parfaite avec des outils open source autohébergés.

On devient maître de notre infrastructure, mais l’on devient dépendant d’une communauté de développeurs et des mises à jour de tout ça.

Et l’open source n’est pas gratuit. Et si l’on n’investit pas du temps à l’interne pour améliorer le projet open source, qui le fera ? On ne connaît pas toujours les acteurs d’une communauté open source.

C’est l’idéal selon moi. Vous amener de l’eau au moulin, tout en utilisant le moulin pour vous.

Ce que j’aimerais communiquer pour améliorer la pérennité de tes projets web

Définir en amont du rôle du projet web dans son entreprise (besoins, problèmes, etc.).

Choisir l’équipe avant de choisir l’architecture technique.

Définir ce qu’on attend lors de la mise en ligne et l’ampleur du support à faire.

Prévoir l’implantation des nouveaux processus dans l’équipe en même temps qu’on conceptualise le projet grâce à l’UX, l’implication dans le développement de l’équipe et les formations.

Favoriser la modularité de l’architecture logicielle pour faciliter l’ajout de fonctionnalité.

Prévoir des fonctionnalités versatiles et adaptées à votre écosystème actuel et potentiel.

Outils pour jouer avec tous ça

J’espère que tu as pu ressortir de quoi de concret pour toi dans tout ça.

Je te promets, j’ai écrit tout ça sans notre ami GP d’open ai. J’ai tendance à vouloir faire des définitions.

La pérennité de logiciel est très difficile à atteindre, parce qu’il y a tellement de couches à prendre en compte. Surtout celles qu’on ne contrôle pas.

C’est comme si ce courriel était une carte des possibles pour ton prochain projet web.

J’aime imaginer le meilleur des mondes, afin de prendre des décisions qui tendent vers ça. Sauf qu’il ne faut pas oublier que l’argent, le temps et l’énergie sont toujours limités et il faut faire des choix.

Le mois en rafale

Mes découvertes

Astro 5 en béta

C’est un framework génial qui permet de générer des sites statiques à partir de structures en markdown et du data dynamique.

Astro en béta version 5

Stripe ouvert un site pour améliorer le DX

J’adore beaucoup d’initiative de stripe.

Stripe.dev

Just for Fun. No, Really.

We like to write software! Coding is a zigzag journey of problem-solving, and the destination is less important than some might think.

justforfunnoreally.dev

Les pratiques de découverte de la population québécoise dans l’environnement numérique varient selon les produits culturels recherchés

Montréal, 10 septembre 2024. – Comment les personnes qui consomment des séries et des films, de la musique, des livres ou des balados au Québec découvrent-elles ces produits sur le Web? Quels sont les sources et les moyens utilisés pour découvrir des contenus québécois en français?

étude sur les méthodes utilisés pour découvrir la culture au Québec

Open cli

Un framework pour développer son CLI

Open cli github

Nouvelles

Intel pourrait être acheté par Qualcomm

Qualcomm essayerait d’acheter Intel. C’est gros, parce que j’ai l’impression qu’on est à l’orée d’un changement de garde majeur dans les processeurs. C’est déjà commencé, avec Apple qui a développé ses propres processeurs avec la technologie ARM, comme la spécialisation de Qualcomm et comme dans vos téléphones portable.

Mon outil

Je présente un outils du mois, soit en mode testé et approuvé, soit en test ou soit en découverte.

2e cerveau avec obsidian

C’est vraiment essentiel un deuxième cerveau en entreprise. Personnellement, je dit que j’en ai 3. Le mien, mon obsidian et mon calendrier.

Obsidian.md

/** Commentaires */

  • Précédent

    Combat les algorithmes avec tes fils RSS #6
    #6


    Combat les algorithmes avec tes fils RSS

  • Suivant

    Mon processus de sevrage de l'apprentissage en série #9
    #9


    Mon processus de sevrage de l'apprentissage en série

Voir tous les numéros