Décider vite ? OK, mais à quel prix ?

Dans l’univers de la Tech, nous sommes régulièrement amenés à prendre des décisions qui auront un impact majeur. Et si chaque décision rapide vous coûtait des milliers d’euros et des mois de travail ? 😱

C’est particulièrement vrai en Data Engineering, MLOps et IA, où les décisions concernent à la fois des sujets (en apparence) purement techniques (quelle base de données choisir ? quelle stack technologique ? etc.) et des enjeux business (comment répondre à un besoin métier ? quel est le besoin en termes de fraîcheur des données ? etc.).

Imaginez ces scénarios :

• On vous demande de choisir une stack MLOps pour répondre aux ambitions en IA de votre entreprise. Comment choisir sans regretter ?
• Une nouvelle activité est lancée, et vous devez mettre en place une ingestion de données critique avec un SLA de 30 minutes. Le PoC a bien fonctionné en dev. Est-ce suffisant pour la production ?
• Un changement métier impose de modifier un composant critique d’une API de recommandation. Vous y parvenez, mais les performances chutent drastiquement, et le composant n’a pas été testé. Quel impact sur le projet ?

Ces exemples illustrent un problème récurrent : les décisions prises sous pression pour répondre à des besoins à court terme peuvent avoir des conséquences désastreuses à long terme. Répondre trop rapidement à un besoin immédiat, n’est-ce pas se tirer une balle dans le pied ? 🤔

L’objectif de cet article est de partager 3 situations vécues, leur impact, et surtout comment on aurait pu faire autrement !

Les coûts cachés du court-termisme 💸

Les décisions précipitées entraînent souvent des coûts cachés, des surprises budgétaires et pire, une baisse de la confiance des utilisateurs.

Prendre des décisions stratégiques rapidement peut sembler judicieux à court terme, mais cela peut entraîner de coûteuses conséquences à long terme. Voici les 3 exemples concrets que j’ai observés :

1. Une stack MLOps mal choisie 🛠️

Un projet de Machine Learning stratégique avait été développé en Python avec des librairies open source. Suite à un changement de direction, une stack propriétaire no code (Dataiku) a été choisie pour faciliter le développement et la mise en production. Résultat : réécriture du code, accompagnement par une société tierce, et finalement, une migration coûteuse vers une 3e solution hybride (Vertex AI) moins d’un an plus tard.

Impacts :

• 2 migrations coûteuses 💸
• Plus de 100 000 € dépensés pour des solutions non adaptées
• Plusieurs mois de perte de productivité 🤦

2. Une mise en production catastrophique 🚨

Une ingestion de données via des fichiers Parquet sur Google Cloud avait été mise en place avec un SLA de 30 minutes. Le PoC fonctionnait bien en dev, mais la volumétrie de production n’avait pas été testée. Malgré les avertissements de l’équipe, la décision a été prise de lancer en production. Résultat : ingestion en échec, debug en urgence, et confiance des utilisateurs en berne.

Impacts :

• Ingestion en échec dès le lancement
• Debug en production sur le chemin critique de la donnée
• Confiance dégradée des utilisateurs

3. Un changement d’algorithme précipité ⏱️

Une API de recommandation bien rodée a dû subir un changement d’algorithme pour répondre à une nouvelle demande métier. Faute de temps, le composant n’a pas été testé, et les performances ont chuté de 100ms à plus de 10 secondes. Résultat : image du produit dégradée et algorithme désactivé peu après.

Impacts :

• Temps de réponse multiplié par 100 🐌
• Image du produit dégradée dès le lancement
• Algorithme désactivé faute de pertinence métier

Ma vision pour éviter ces erreurs 🚀

1. Gardez la confiance utilisateur à tout prix 🔑

La confiance des utilisateurs est la clé du succès d’un projet Tech. Commencer simple, éviter les solutions complexes, et livrer un produit qui répond à un besoin métier basique. Ensuite, faites évoluer le produit par itérations successives.

2. Pensez long terme 📅

Pourquoi distinguer PoC et production ? Avant même de tester une idée, définissez les bases de la solution. Posez-vous les bonnes questions :

• La solution répond-elle à nos besoins ?
• Est-elle évolutive et scalable ?
• Quel est le coût total de possession (TCO) ?

Privilégiez des solutions robustes et éprouvées comme Airflow, Docker, Kubernetes, Terraform, ou FastAPI. En MLOps, optez pour MLflow ou Kubeflow.

3. Impliquez votre équipe 👥

Faites participer vos experts techniques dès la conception. Leur feedback peut éviter des erreurs coûteuses et garantir que la solution répond aux besoins réels. Leur adhésion est cruciale pour le succès du projet.

4. Adoptez une approche FinOps 💡

Intégrez une réflexion sur les coûts dès le départ. Comparez les modèles économiques des solutions (ex. Snowflake vs PostgreSQL) et prévoyez une migration facile si nécessaire. Une semaine d’étude supplémentaire peut vous faire économiser des milliers d’euros et éviter de ternir l’image d’un produit lancé trop tôt.

5. Documentez et communiquez 📄🗣️

Documentez chaque décision (ADRs) et partagez-la avec l’équipe. Une documentation claire fait gagner du temps et évite les erreurs. Et si demain vous n’êtes plus là, votre projet doit pouvoir continuer sans vous.

6. Garder de la flexibilité face aux enjeux métier 📈

Les équipes techniques et les équipes métier ont souvent des priorités distinctes :

• Les équipes techniques se concentrent sur la conception, la mise en œuvre et la maintenance d’outils robustes et pérennes. En clair elles pensent souvent long terme et peuvent être réticentes aux changements rapides.
• Les équipes métier visent à capitaliser sur des opportunités commerciales concrètes et à répondre rapidement aux évolutions du marché.

Il faut donc bien évidemment ne pas rester rigide sur les éléments ci-dessus et trouver un équilibre entre la stabilité long terme d’une solution et la réactivité aux besoins métier.

Conclusion

Le but de cet article est de vous partager des pistes de réflexion pour éviter les erreurs que j’ai pu observer ces dernières années.

Cela m’amène maintenant à évoquer une dernière chose : de quelle façon avons nous le meilleur impact pour une boîte lors de ce type de situation ? L’objectif d’une entreprise étant de générer de la valeur, on peut reformuler la question : comment maximiser la valeur que l’on apporte à la boîte lors de ce type de décision ?

En répondant à des demandes métier, mêmes si elles vont à l’encontre des intérêts de l’entreprise ? Est-ce une bonne chose de saisir une opportunité qui coûtera plus qu’elle n’apportera ? Je ne pense pas que ce soit la bonne façon de faire.

Il faut parfois savoir dire non , cadrer les attentes, et penser avant tout à la valeur apportée de façon globale. Mais en le faisant en partenariat avec les équipes métiers ! Afin de trouver la solution la plus adaptée et qui aura le meilleur impact sur le long terme.

Prendre le temps de bien réfléchir à vos choix technologiques est un investissement qui paiera à long terme. Évitez les regrets en privilégiant la qualité sur la rapidité.

Pour aller plus loin

Dans mon rôle de Fondateur d’une start-up, je me pose ces questions à une échelle encore plus large. Comment poser des bases solides, évolutives et performantes tout en restant agile ?

Je documenterai mes réflexions, décisions et surtout mes erreurs sur mon blog !

Un teaser : une architecture conteneurisée avec Docker, des outils de CI/CD pour des itérations rapides, tout cela afin de poser les bases de migration de Cloud Run vers Kubernetes pour réduire les coûts à terme.

Restez connectés pour la suite ! 🚀

À propos de cet article

Cet article traite d’un sujet récurrent dans les boîtes Tech : les décisions techniques ! On rencontre notamment ces décisions dans les sujets Data Engineering, DevOps et IA.

Si vous souhaitez en savoir plus sur ces sujets, contactez-moi directement par mail 📩.