Je vous propose un retour d’expérience, celui de YEAP, le troisième éditeur dont j’ai la charge. ceci n’est donc pas une étude exhaustive, mais j’espère qu’elle vous aidera lors de vos prochains choix logiciels.
L’expérience, est la clé, savoir ne pas se précipiter est le leitmotiv.
Vision globale
Un éditeur doit avoir une vision globale de la solution qu’il s’apprête à développer, savoir ou le produit va atterrir permet de construire des fondations solides et complètes.
Les logiciels historiques sont souvent issus de constructions empiriques, elle génèrent des solutions hybrides, constituées de briques hétérogènes.
Ces gammes de produits deviennent alors instables, et une modification infime peut engendrer des effets de bords désastreux.
C’est probablement la première cause qui doit vous inciter à regarder les nouveaux acteurs du marché.
Prendre son temps
La précipitation est le facteur N°1 de l’échec d’un éditeur, qui devra assumer durant de longues années les quelques mois d’investissement qu’il n’a pas su protéger au démarrage.
Pressé de démarrer, de livrer une V1 pour facturer, afin de se prouver ou de prouver à ses financeurs qu’il ne s’est pas trompé, que le marché est là, qu’il à le savoir faire.
Il en résulte de mauvais choix, techniques, d’architecture, même parfois de prise de raccourcis sur les aspects fonctionnels, la précipitation est mauvaise conseillère.
L’informatique a besoin de fondations, les écrans sorti à la hâte ne sont que la partie émergée d’un iceberg qui brille au soleil (et qui va fondre, logiquement), il faut toujours s’intéresser à ce qui ne se voit pas.
Investir dans les tests
Minorer la place des tests, voir ne pas en mettre en place, nombre d’éditeurs traitent les tests de manière empirique, absence de procédure, procédures manuelles, les cas sont bien plus nombreux que vous ne pouvez l’imaginer.
Un éditeur doit penser test avant de penser développement, il doit développer les tests puis la fonction, c’est la seule manière de garantir une maintenabilité dans la durée,
Ne jamais sacrifier la maintenabilité et la qualité pour une productivité de façade.
Piloter par le niveau requis et non par la date de sortie
La V1 ne doit pas être une finalité, elle ne doit pas induire d’impasses ou d’exclusions dans le seul but de satisfaire un besoin de présentation. La façade n’est que de l’habillage.
Avoir ses premiers clients, tant important que ce soit, est la première étape de la mise en place d’un service support et de sollicitations auprès des équipes de développement. Il faut savoir attendre que le produit ait réellement la maturité nécessaire avant de le proposer au marché.
Il faut donc maîtriser sa couverture fonctionnelle, pour chiffrer une roadmap, constituer une équipe adaptée aux exigences et aux délais… et non l’inverse.
Explorer les territoires inconnus.
On utilise toujours ce que l’on connaît, chaque expert dans un langage ou une technologie vous démontrera qu’il est le meilleur, la maîtrise d’un outil implique parfois un aveuglement qui empêche de regarder ce qui se fait ailleurs.
Ne pas regarder ailleurs, ne pas se faire conseiller, ne pas tester de solutions, voilà le meilleur moyen pour ne pas innover.
Il faut perdre du temps à explorer les solutions techniques du jour, faire et parfois défaire, si vous avez respecté le précepte de la mise en oeuvre des tests automatiques, faire et défaire n’est pas si coûteux.
Ce précepte est la première cause de l’absence d’innovation chez vos éditeurs historiques, personne n’aura le courage, dans une structure importante et hiérarchisée, de bousculer les sachants pour apporter de la nouveauté.
Alors Yeap sera t’il la meilleure paie ?
Je n’ai aucune prétention ni légitimité pour faire des annonces invérifiables. Je ne répondrai donc pas à cette pseudo question que je pose pas simple provocation.
Ce que je sais, je peux le dire, en 6 mois :
- Nous n’avons travaillé que nos fondations, choix techno et console de modélisation (outils internes pour pérenniser la maintenabilité des règles de calculs).
- Nous avons changé de langage une fois
- Nous avons changé de base de données une fois
Tout ceci ne nous a pas coûté trop cher, car nous avions mis en place les procédures et outils de tests,
- Cypres pour le front,
- Postman pour les Api.
A ce jour, plus de 2000 tests tournent à chaque évolution, et cette base s’enrichit tous les jours. La non régression applicative en dépend.
Nous respectons les cycles de productions en vigueur en agilité.
Les products owner savent ou le produit va atterrir, la vision est globale, l’architecture construite pour y répondre.
Poser les bonnes questions
Finalement lorsque vous souscrivez à une offre logicielle, posez vous les bonnes questions.
- Ai je en face de moi une structure qui maîtrise réellement mon activité, qui connaît mes usages ou est elle une pro du marketing.
- Ai je en face de moi une structure qui respecte les fondamentaux de l’édition logicielle, la sécurité la disponibilité le respect de la propriété des données.
- Ai je en face de moi un éditeur innovant ou juste un acteur qui maintien une solution, certe éprouvée, mais probablement épuisée.
- Le web n’est pas une innovation, quelle sont les technologies utilisées, quelle sont les cycles de développement.
- La solution est elle scalable (que va t’il se passer si les volumes augmentent fortement)
Pour aller plus loin, votre éditeur est’il hébergé au sein d’un cloud souverain? Vos données doivent être hébergées en France, mais cela ne suffit pas, les Gafam vous hébergent en France ou en Europe mais elles dépendent du Patriot Act Américain, vos données ne sont pas en sécurité, la confidentialité n’est pas garantie.
Mon conseil, faites vous accompagner, composez une équipe constituée de vos sachants mais aussi de professionnels de la tech.
Un dernier pour la route, ne répondez pas aux sirènes du marketing qui vous vendent de l’IA là ou il n’y a que des algorithmes (ce pourrait être un post à part entière)
N’hésitez pas à partager vos avis 🙂 merci
