Delivery & run / Mise en production

Déployer en production est toujours un moment de stress. La bonne nouvelle, c’est qu’avec une méthode claire, ce stress peut devenir maîtrisable.

Pourquoi une mise en production fait toujours peur

Une mise en production, c’est une avalanche de questions : Est-ce que j’ai pensé à tout ? Est-ce que j’ai bien testé ? Est-ce que je ne vais pas tout casser ? Est-ce que je ne vais pas perdre mon référencement ?

Et très vite, on se dit : comment je vais continuer à innover, livrer plus vite, développer de nouvelles fonctionnalités, sans être en panique à chaque déploiement ? La réponse n’est pas magique. Elle repose sur une discipline claire et une checklist maîtrisée.

1) Savoir exactement ce que l’on déploie

Avant même d’écrire une ligne de code, il faut être capable d’expliquer clairement ce que l’on va mettre en production. Ça passe par :

une documentation claire
des objectifs précis
une compréhension partagée de la fonctionnalité

Cette documentation sert autant à l’équipe actuelle qu’aux personnes qui rejoindront le projet plus tard. Déployer sans savoir exactement ce que l’on déploie est la meilleure façon de perdre le contrôle.

2) Définir les cas de test avant de foncer

Les cas de test ne sont pas un luxe. Ce sont des garde-fous. Ils permettent de savoir quoi tester, comment tester et de réduire l’incertitude. Tests automatisés ou tests manuels, les deux sont nécessaires. Avoir des cas de test écrits permet d’aborder la mise en production avec beaucoup plus de sérénité.

3) Tester dans un environnement dédié (staging, pré-prod)

L’essentiel est d’avoir un environnement qui permet de tester ce qui va être déployé sans impacter les utilisateurs finaux. Cet environnement doit être le plus proche possible de la production :

même configuration
mêmes dépendances
mêmes contraintes

Tester ailleurs qu’en conditions réalistes donne un faux sentiment de sécurité.

4) Automatiser pour accélérer et sécuriser

Pour déployer sereinement et souvent, l’automatisation est indispensable. L’objectif de la CI/CD est d’automatiser les builds, les tests et les contrôles de qualité (SonarQube, Lint, scan de sécurité comme Snyk). Mais attention, automatiser les outils ne suffit pas sans une stratégie globale.

5) Mettre des garde-fous dans les pipelines

Un pipeline sans garde-fous est une autoroute vers les incidents. C’est une règle non négociable avant un déploiement :

tests automatisés exécutés systématiquement
code coverage minimum atteint
tests critiques obligatoirement au vert

L’équipe ne peut pas déployer tant que ces critères ne sont pas respectés. Ce n’est pas de la rigidité, c’est de la protection.

6) Classifier les tests selon leur criticité

Tous les tests n’ont pas la même importance. Certains sont vitaux pour le business (paiement, authentification, accès aux données), d’autres sont utiles mais moins bloquants. L’important est de savoir quels tests doivent absolument passer avant une mise en production.

7) Planifier et communiquer la release

Une release ne se fait pas dans le silence. Il faut définir ce qui va être livré, communiquer sur les nouvelles fonctionnalités et préparer les utilisateurs. C’est un élément clé de la réussite, surtout sur des plateformes SaaS interconnectées.

8) Utiliser des feature flags pour réduire le risque

Les feature flags permettent de déployer une fonctionnalité sans l’activer, de l’activer ou la désactiver à distance et de réagir rapidement en cas de problème. Le code est en production, mais le risque est maîtrisé.

9) Avoir une vraie stratégie de rollback

Une bonne stratégie de rollback inclut des conteneurs capables de redémarrer proprement, des backups de base de données avant déploiement et un retour en arrière déclenchable facilement. L’utilisation de Kubernetes avec des déploiements Canary permet de s’assurer qu’aucun switch n’est effectué tant que le nouveau conteneur n’est pas opérationnel.

10) Ne pas oublier les pages de maintenance

Si une micro-coupure est nécessaire, prévenez vos clients et choisissez des créneaux adaptés. Une bonne communication vaut mieux qu’un silence inquiétant.

Conclusion

Déployer en production sans trembler n’est pas une question de chance. C’est une question de méthode, d’automatisation, et de discipline. Plus votre checklist est claire, plus vos déploiements deviennent prévisibles. Et quand la production devient ennuyeuse, c’est généralement bon signe.

Winzana / Retour d’expérience

Les premières années de Winzana ont été pleines d’envie, d’ambition… et d’erreurs. Certaines nous ont presque coûté l’entreprise.

Les débuts au forfait : l’envie de bien faire… à tout prix

Nos premières vraies heures ont commencé avec des projets au forfait. Sur le papier, tout semblait cadré : des spécifications rédigées, des échanges détaillés, une vraie volonté de structurer. Mais dans la réalité, on n’osait pas trop dire non.

On avait cette envie profonde de faire plaisir, de faire en sorte que le business de nos clients fonctionne, quitte à accepter “un petit plus”, puis un autre, puis encore un. À ce moment-là, on pensait encore que la bonne volonté pouvait compenser les dérives.

Les premières mises en production… et la spirale

Puis sont arrivées les premières mises en production. Et avec elles, des clients de plus en plus exigeants. Pas par méchanceté. Simplement parce qu’une brèche était ouverte. Les demandes ont commencé à s’enchaîner :

“Ce serait bien si…”
“Ça ne devrait pas être très compliqué…”
“On peut l’avoir sans surcoût ?”

Et nous, encore une fois, on disait oui. Pas par faiblesse. Par manque de maturité.

Quand la tête passe sous l’eau

Petit à petit, la situation est devenue intenable. Des semaines à 80 à 100 heures de travail, enfermés dans le garage, à développer comme des malades. Pas pour innover. Pas pour améliorer le produit. Mais pour honorer des engagements qu’on n’aurait jamais dû prendre. À ce moment-là, tu ne construis plus. Tu survis.

2017–2018 : de beaux projets… et une quasi-faillite

2017–2018 ont été les années les plus difficiles. Techniquement, on sortait de très beaux projets, ambitieux, avec des choix technologiques forts. Mais financièrement, c’était un désastre. Conditions de travail déplorables, pression constante, épuisement, et une société au bord du gouffre. On était littéralement à une semaine de fermer la boîte.

Les équipes, elles, ont toujours été incroyables

S’il y a une chose qui n’a jamais failli, ce sont les équipes. Des gens engagés, compétents, solidaires. Et c’est probablement ce qui rendait la situation encore plus dure : savoir que tout le monde se donnait à fond, mais que le modèle n’était pas viable.

La sortie de crise : le retour au consulting

Puis, une fois encore, la chance nous a souri. On a trouvé de nouveaux projets en consulting. Des projets financièrement attractifs, plus simples à cadrer, plus sains. Ces projets nous ont permis de sortir la tête de l’eau, de respirer, et de reconstruire. Sans ça, Winzana n’existerait probablement plus aujourd’hui.

Non, ce n’était pas la faute des clients

Je tiens à être très clair : je ne rejette pas la faute sur nos clients. Ils ont été exigeants, ils ont demandé plus. Qui ne le ferait pas pour obtenir un maximum de valeur à moindre coût ? L’erreur était la nôtre. Nous n’avons pas su dire non au bon moment.

Se casser les dents pour grandir

Comme disent les Américains : “First, fail.” On s’est cassé les dents sur des projets, des choix techniques, des décisions business et sur l’incapacité à poser des limites. Mais ces erreurs nous ont construits. Elles nous ont appris :

à mieux cadrer
à être plus carrés
à protéger l’entreprise et les équipes

L’importance de bien s’entourer

Cette période nous a aussi appris à ne pas rester seuls. On s’est entourés d’amis entrepreneurs, techniciens et avocats. Des gens capables de dire les choses, de challenger nos choix, de nous éviter de refaire les mêmes erreurs. L’entrepreneuriat n’est pas un sport solitaire. Ceux qui l’oublient le paient cher.

Conclusion

Ces premières erreurs nous ont coûté cher financièrement, humainement et mentalement. Mais elles ont aussi posé les bases de la Winzana d’aujourd’hui : une entreprise plus structurée, plus lucide, et surtout plus capable de dire non quand il le faut. On ne souhaite ces moments à personne, mais avec le recul, ils font partie intégrante du chemin.

Organisation & delivery / Squads à la Spotify

Les squads “à la Spotify” font rêver beaucoup d’organisations. Dans la réalité, elles échouent souvent… pas par manque de talent, mais par manque d’alignement et de pragmatisme.

C’est quoi, une squad à la Spotify ?

Avant de critiquer le modèle, il faut déjà expliquer de quoi on parle. Le modèle “Spotify” repose sur des squads :

des équipes autonomes
pluridisciplinaires
responsables d’un périmètre métier précis

Une squad regroupe généralement : développeurs, QA, product owner, parfois UX. L’idée est simple et séduisante : donner de l’autonomie, réduire les dépendances, accélérer la delivery. Sur le papier, c’est brillant. Sur le terrain… c’est plus complexe.

L’organisation d’équipe : le vrai sujet, pas la méthode

Aujourd’hui, beaucoup d’entreprises parlent de “shift left”, de squads, de responsabilités poussées au plus près des équipes. Les cabinets de conseil regorgent d’articles, de schémas, de frameworks clés en main. Mais l’organisation d’équipe n’est pas une méthode à copier-coller. C’est un système vivant, qui doit s’adapter au contexte du SI, à la maturité des équipes et aux enjeux business.

Pourquoi les squads échouent souvent dans les grands SI

Le premier problème, c’est que chaque squad tente de réinventer la roue. Chaque équipe choisit ses technos, met en place ses outils et définit ses propres standards. À court terme, ça fonctionne. À long terme, c’est un désastre. On se retrouve avec :

une multiplication des langages
une explosion des frameworks
des architectures incohérentes

Et surtout, des solutions qui ne parlent pas entre elles.

L’illusion de l’alignement par l’architecture d’entreprise

En théorie, l’architecture d’entreprise est là pour donner une vision et des principes macro. En pratique, c’est rarement suffisant. Sans garde-fous techniques concrets (choix technologiques, standards de développement, cohérence des patterns) supervisés au quotidien, les dérives sont inévitables

Startup & business / Bootstrapping vs levée de fonds

Créer une startup sans lever de fonds fait rêver. Mais est-ce une vraie stratégie ou juste un fantasme d’entrepreneur ?

Créer une startup coûte toujours quelque chose

Monter une startup, ça coûte de l’argent. Toujours. Mais mettre la main au porte-monnaie ne veut pas forcément dire sortir du cash immédiatement. Ça peut aussi vouloir dire :

passer beaucoup de temps
mobiliser ses propres compétences
s’appuyer sur des proches, des amis, des associés

Le capital de départ, ce n’est pas toujours de l’argent. C’est souvent du capital humain.

Un contexte beaucoup plus frileux côté investisseurs

Il y a quelques années, les fonds investissaient massivement, parfois très tôt. Aujourd’hui, le contexte est différent. Les marchés sont plus frileux. L’arrivée de l’IA a aussi changé la donne : certains investisseurs préfèrent attendre et voir comment les usages vont évoluer avant de s’engager. Résultat : lever des fonds est devenu plus compliqué, plus long et plus exigeant.

Faut-il obligatoirement lever des fonds pour lancer sa startup ?

La réponse honnête est : oui et non. Si tu es développeur et que tu veux lancer une startup technologique, tu pars déjà avec un capital énorme : toi-même. Tu peux :

développer ta plateforme seul
t’associer avec un ou deux amis
sortir un premier produit sans équipe complète

Aujourd’hui, avec des outils comme Figma, tu n’as même plus forcément besoin d’un graphiste au départ pour produire quelque chose de propre. Ta première “levée de fonds” est souvent une levée de fonds humaine.

Le vrai problème : la commercialisation

Là où beaucoup de startups se cassent les dents, ce n’est pas sur la techno, c’est sur le business. Beaucoup de profils techniques ne sont pas naturellement des commerciaux ou des marketeurs. Développer un bon produit ne suffit pas à le vendre.

Faut-il s’associer avec un commercial ?

Il n’y a pas de réponse universelle. Cela dépend de ton marché, de ton type de clients et de ta capacité à vendre toi-même. S’associer avec un commercial peut être une excellente idée… ou une très mauvaise si l’alignement n’est pas là.

Le moment où le cash devient indispensable

Au début, tu peux compenser avec du capital humain. Mais rapidement, certaines dépenses deviennent incontournables :

communication et marketing
référencement (SEO / SEA)
influenceurs, partenariats

À ce moment-là, tu ne peux plus uniquement donner de ton temps. C’est là que la levée de fonds commence à devenir un accélérateur intéressant.

Love money, fonds, banques : des chemins très différents

La levée de fonds ne veut pas forcément dire faire entrer un gros fonds d’investissement. Il existe plusieurs options : la love money, les aides publiques, les banques ou les fonds spécialisés. Mais plus on monte en professionnalisation, plus les exigences augmentent. Cela demande d’être un excellent orateur, de pitcher clairement et de produire des dossiers solides.

Lever des fonds, c’est aussi changer de métier

Beaucoup sous-estiment ce point. Le temps que tu as passé à développer ta solution, il faudra en passer deux fois plus, voire dix fois plus, à pitcher, rencontrer, convaincre et négocier. Lever des fonds est quasiment un métier à part entière pendant plusieurs mois.

Et chez Winzana ? La stratégie de la patience

Chez Winzana, on n’a jamais levé de fonds par choix. Résultat : on existe depuis plus de dix ans. On n’est pas multimillionnaires, mais on est indépendants, stables et pérennes. Tout l’argent gagné reste dans l’entreprise pour financer notre croissance à notre rythme.

Conclusion

Créer une startup sans lever de fonds n’est ni un fantasme, ni une solution miracle. C’est une vraie stratégie à condition d’être patient, lucide et conscient des limites. Lever des fonds peut être un accélérateur puissant, mais ce n’est jamais gratuit en termes de temps, d’énergie et de contrôle. La vraie question est : quel rythme de croissance est compatible avec ta vision ?