Le document présente des stratégies sur la façon de s'adapter à la croissance d'une startup, en soulignant que 90% des startups échouent en raison de divers problèmes liés à la gestion, à l'efficacité et à la performance. Il propose des conseils sur la priorisation des fonctionnalités, l'optimisation des outils et infrastructures, ainsi que sur l'importance de la documentation et du partage d'expérience au sein de l'équipe. Enfin, il insiste sur la nécessité d'une bonne communication interne et de l'anticipation des problèmes pour maintenir une croissance réussie.

1. Comment s’adapter
à la croissance
d’une startup ?

2. @lboix
Lucien Boix
◇ 31 ans
◇ Développeur Rails / Java & DevOps
◇ Je viens de Lyon (France)
◇ Je vis depuis 4 ans à Montréal (Québec, Canada)

3. “
90% des startups échouent
(Forbes, Fortune)

4. C’est un mythe
◇ Durée de vie non définie clairement
◇ Définition d’échouer ?
◇ En fait
￭ 66% survivent jusqu’à la 2ème année (Small
Business Administration, USA)
￭ 50% survivent jusqu’à la 5ème année (US
Bureau of Labor Statistic)

5. Quelles sont les raisons
principales d’échec
d’une startup ?
?

6. CB Insights
◇ L’explique dans cette étude
◇ 101 interviews post-mortem
◇ Multiples raisons regroupées en 20 catégories

7. Processus
Le top 3 des raisons liées

8. 13%N’avaient pas le bon focus
8%Des investisseurs n’étaient pas intéressés : performance
8%Les fondateurs ont fini en burnout : efficacité

9. Nous en déduisons une
mauvaise gestion de la
croissance
Suivons nos 3 mots-clés et définissons un plan

10. Comment s’adapter à la
croissance d’une startup ?
◇ Focus : qu’est-ce qu’on fait ?
◇ Efficacité : comment bien le faire ?
◇ Performance : comment l’améliorer ?
￭ Faire mieux
￭ Faire plus

11. Une startup qui a relevé
le défi
◇ Solutions Médias 360
￭ 278 clients
￭ 762 websites
◇ Fondée en 2010 avec 4 employés
◇ J’étais le 51ème en septembre 2013
◇ Nous sommes un peu plus de 140 en
mars 2017

12. Focus
Tracking des features / demandes
1

13. Quantifier
Vous devez être capable de
mettre des chiffres sur la
santé de l’équipe
1 - Focus Tracking des features / demandes

14. En mode projet
◇ Un sprint de X points
◇ Une release contenant Y
évolutions
C’est à dire
En mode support
◇ Un nombre de tickets
ouverts
◇ Un nombre de tickets
fermés
1 - Focus Tracking des features / demandes

15. Mode projet en détail
◇ Objectif : gérer des releases
￭ Contenu
￭ Date de livraison
￭ Suivi de l'avancement
◇ Outils possibles
￭ Jira (Atlassian)
￭ Youtrack (Jetbrains)
￭ Issue tracker de GitHub ou GitLab
1 - Focus Tracking des features / demandes

16. Mode support en détail
◇ Objectif : mettre l’énergie à chaque instant sur le bon sujet
￭ 1 situation = 1 ticket
￭ Chaque ticket a le bon SLA
￮ Service Level Agreement
◇ Outils possibles
￭ Jira Service Desk (Atlassian)
￭ ZenDesk
1 - Focus Tracking des features / demandes

17. On ne veut pas entendre
◇ “Ça va bien en ce moment”
◇ “On est dans le rush”
◇ Qu’est-ce que cela veut dire ?
◇ “Développons et on verra bien”
◇ “On reçoit trop de courriels dans support@yourcompany.com”
◇ Aucune idée de notre performance
1 - Focus Tracking des features / demandes

18. Mais plutôt pour le projet
◇ “On n’a réussi à livrer que 35 points sur les 45 promis”
￭ Technique de pointage à revoir ?
￭ Tâches bien découpées ?
◇ “On a terminé le sprint 2 jours en avance”
￭ Félicitons-nous!
￭ Performance peut-être sous-estimée
1 - Focus Tracking des features / demandes

19. Et pour le support
◇ “On a 30% de tickets supplémentaires cette semaine”
￭ Besoin de renforts
￭ Régressions dans le dernier déploiement ?
◇ “On ferme 80% de nos tickets en respectant le SLA”
￭ Félicitons-nous!
￭ Comment viser le 85% ?
1 - Focus Tracking des features / demandes

20. La finalité
◇ Base pour améliorer l’efficacité et la performance future
￭ Anticiper & adapter l’équipe
￭ Viser l’amélioration continue
￮ Projet : + d’évolutions livrées
￮ Support : tickets fermés plus vite (niveau 1)
Moins de tickets rentrants (niveau 2)
1 - Focus Tracking des features / demandes

21. Efficacité
Infra & outils de travail
2.1

22. Rentabiliser
Ne perdez pas de temps en
gestion d’infra
2.1 - Efficacité Infra & outils de travail

23. Minimiser la maintenance
◇ Considérez
￭ Heroku
￭ Amazon Web Services
￭ Google Cloud Platform
◇ Plutôt que de gérer vos propres serveurs
◇ Attention : vos applications devront être “cloud ready”
2.1 - Efficacité Infra & outils de travail

24. Ce qu’on redoute
◇ “On a des backups de la prod ?”
◇ “Il n’y a plus d’espace disque sur le serveur”
◇ “Une faille de sécurité doit être corrigée au plus vite”
◇ “Notre serveur s’est fait hacké”
◇ “Il faut mettre à jour JIRA”
2.1 - Efficacité Infra & outils de travail

25. Valable aussi pour vos
outils
◇ Externaliser
￭ Sauf contraintes particulières
◇ Courriels & suite bureautique
￭ G Suite (Google Apps)
￭ Office 365 Business (Microsoft)
◇ Serveurs FTP (ex. ExaVault)
◇ Mass mailing (ex. MailChimp)
◇ Gestion de parc informatique ?
2.1 - Efficacité Infra & outils de travail

26. La finalité
◇ Coût financier plus important mais
￭ Moins de stress
￮ Focus
￭ Temps économisé
￮ Réinvesti sur le produit
◇ Gain à moyen-long terme indéniable
2.1 - Efficacité Infra & outils de travail

27. “Ne jamais sous-
estimer une migration”
2.1 - Efficacité Infra & outils de travail

28. Efficacité
Qualité projets
2.2

29. Définir
En équipe, le plus tôt,
comment amener le code en
production
2.2 - Efficacité Qualité projets

30. Code
◇ La qualité de l’application commence ici
◇ Définissez vos propres règles pour l’assurer
￭ Merge requests
￭ Git Hooks
￭ Pair review
2.2 - Efficacité Qualité projets

31. Tests
◇ Stratégie à mettre en place dès le lancement du projet
￭ “On les fera plus tard”
2.2 - Efficacité Qualité projets

32. Tests
◇ S’arrête-t-on au niveau de l’API ?
￭ Point d’entrée du backend
◇ On inclut les tests de navigation Web ?
￭ Selenium, Phantom.js
￮ De réputation lourds à maintenir
￮ Cela change (ex : Screenster)
◇ C’est votre choix
2.2 - Efficacité Qualité projets

33. Intégration continue
◇ “push to prod”
◇ Concept de pipelines
￭ Heroku, GitLab, BitBucket
￭ Ou votre plan custom
￮ Prend une équipe mature
2.2 - Efficacité Qualité projets

34. Outils de déploiement
◇ “ssh / ftp”
◇ Jenkins, Bamboo, Travis CI, TeamCity
￭ Plus d’erreur humaine possible
￭ TODO auto-documentée dans l’outil (tasks)
￭ Rollback rapide
◇ Migration de version critique
￭ Backup obligatoire
￭ Être capable de rollback
￮ “comme si rien ne s’était passé”
2.2 - Efficacité Qualité projets

35. Une vraie staging
◇ Même environnement
◇ Données de production
￭ Nettoyées
◇ Routines désactivées
◇ Comptes de type “sandbox”
￭ APIs externes
2.2 - Efficacité Qualité projets

36. Tirs de performance
◇ Tester votre application face à une charge inhabituelle
◇ Apache JMeter ou alternative
◇ Il vaut mieux découvrir son point de contention
￭ À l’avance
￭ Que trop tard
◇ “Deadlock au déjeuner”
2.2 - Efficacité Qualité projets

37. La finalité
Détecter un problème avant qu’il
ne se rende en production
2.2 - Efficacité Qualité projets

38. Efficacité
Monitoring
2.3

39. Anticiper
Être au courant le premier
d’un problème
2.3 - Efficacité Monitoring

40. Disponibilité
◇ “Allo ? Mon site est down ?!”
◇ N’oubliez pas : vous êtes une jeune entreprise!
◇ Il est primordial de montrer que vous être en contrôle
￭ Crédibilité
￭ Valider votre expertise
◇ Exemples d’outils
￭ UptimeRobot
￭ Pingdom
2.3 - Efficacité Monitoring

41. Erreurs applicatives
◇ Ne les ignorez pas
◇ Plusieurs techniques
￭ Courriel (1 par erreur)
￭ Outil les agrégeant : ex. Raygun, Sentry
◇ Stratégie à adapter selon votre réalité
￭ Volumétrie
￭ Temps réel ou un check quotidien
2.3 - Efficacité Monitoring

42. Routines
◇ On n’a pas le réflexe de les monitorer
◇ Pourtant traitements essentiels
￭ Import de données (stocks)
￭ Export de données (commandes)
￭ Calcul de points (fidélité)
￭ etc.
2.3 - Efficacité Monitoring

43. Routines
◇ Vous devez savoir si une routine
￭ ne tourne plus à l’heure prévue
￭ dure trop longtemps
￭ ou ne s’arrête plus
◇ Outils
￭ Cronitor
￭ Dead Man's Snitch
2.3 - Efficacité Monitoring

44. Performance
◇ Est-ce qu’elle se dégrade au fil du temps ?
￭ Si oui à quel niveau ?
◇ Temps de réponse, load, % d’erreurs, etc.
◇ Outils
￭ NewRelic
￭ Netuitiv
2.3 - Efficacité Monitoring

45. Comment tout centraliser ?
◇ Des outils existent
￭ PagerDuty, VictorOps
￭ Intégrations par dizaines
◇ PagerDuty
￭ Niveaux d’alertes
￭ Plages horaires “on call”
￭ Bonne application mobile
◇ Une seule place à surveiller
￭ Communication centralisée en cas d’incident
2.3 - Efficacité Monitoring

46. La finalité
◇ Une place unique à
surveiller
◇ Plaisir d’être en
contrôle
◇ Sérénité pour travailler
2.3 - Efficacité Monitoring

47. Efficacité
Rôles
2.4

48. Distribuer
Les responsabilités sont
données à un rôle, et non une
personne
2.4 - Efficacité Rôles

49. Ces rôles se transmettent
◇ À chaque semaine ou mois, dépend du contexte
◇ Exemples
￭ Gestion des erreurs applicatives
￭ Alertes en heures non ouvrées
￭ Réception des appels
￭ Etc.
◇ La mission de chaque rôle est documentée
2.4 - Efficacité Rôles

50. La finalité
◇ Peu d’impact en cas de congé ou d’imprévu
￭ Le rôle tenu sera attribué à un autre
◇ La business va tourner
￭ Même légèrement au ralenti
2.4 - Efficacité Rôles

51. Performance
Documentation
3

52. Capitaliser
Vous ne devez pas chercher
plus d’une fois la même
chose
3 - Performance Documentation

53. Garder une trace 1/2
◇ TODO de configuration
￭ Nouveau client, magasin, feed, etc.
￭ “Il faut utiliser un setup particulier pour ce profil”
◇ Déploiements
￭ TODO auto-documentée normalement (on l’a vu)
￭ Sinon l’écrire quelque part
◇ Pannes
￭ Workaround connu
￭ “Il faut redémarrer les services dans cet ordre”
3 - Performance Documentation

54. ◇ Accès & mots de passe
￭ “expenses@yourcompany.com”
◇ Contacts-clés chez les prestataires
◇ Snippets de code intéressants
￭ Peut aider un autre projet
3 - Performance Documentation
Garder une trace 2/2

55. Rien dans “la tête des gens”
◇ Ou leurs notes personnelles
￭ On veut le partager
◇ “Le gars qui sait tout”
￭ Scalabilité : zéro
￭ Attention : plus on en garde, plus on en prend
￭ Plus de stress pour lui et l’équipe
3 - Performance Documentation

56. Transmettre le savoir
Je le fais
Je le
documente
Je le diffuse
3 - Performance Documentation

57. Stratégie pour documenter
◇ Outil simple et convivial
￭ Aller plus loin que le wiki de base
￮ Notes de réunions, tâches, liens vers tickets. etc.
◇ Exemples d’outil
￭ Confluence (Atlassian), Nuclino
￭ Voir Google Drive
3 - Performance Documentation

58. Stratégie pour documenter
◇ Un processus décidé en équipe
￭ Si pas d’adhésion, cela ne sert à rien
◇ On se met d’accord sur
￭ Quoi commenter
￭ Et où
◇ Réflexe de chercher si un sujet n’existe pas déjà
3 - Performance Documentation

59. La finalité
◇ Scale up efficacement
￭ Inutile de rajouter du monde
￭ Si chacun cherche dans son coin la même info
◇ Gagner du temps
￭ Focus et énergie sur le produit comme on l’a dit
￭ Pas sur la recherche d’un cas déjà arrivé
￮ On ne tourne pas en rond
3 - Performance Documentation

60. ◇ Atteindre le niveau 2
￭ Moins de tickets en entrée
◇ Comment ?
￭ En créant une base de connaissances
￭ Avec les questions / réponses récurrentes
◇ Client satisfait
◇ Renforce sa confiance
◇ Les agents peuvent consacrer leur temps à des cas plus
compliqués
La finalité (mode support)
3 - Performance Documentation

61. Partage d’expérience
Création d’une équipe d’Opérations au sein de Solutions Médias 360

62. Branche OPS de DevOps
◇ Remplit l’espace entre les
développeurs et les chargés de
compte
◇ 1ère ligne de l’équipe projet
◇ Une des réponses à la croissance

63. Missions
Maintenance
Des projets important /
exportant des données
quotidiennement
Communication
En interne (maintenance,
pannes) ou avec les
prestataires externes
Filtrer
Bug, feature ou mauvaise
connaissance de l’outil ?
Configurer
Préparer et coordonner
l’arrivée d’un client ou son
départ
Gestion noms de
domaine
Et certificats SSL
Challenger
Les processus, lever les
flags

64. Évolution
◇ J’ai commencé seul avec un développeur en rotation
￭ Octobre 2014
◇ Première recrue printemps 2015
◇ 4 employés actuellement

65. 9,928Tickets traités

66. 81%De tickets fermés en respectant le SLA annoncé

67. Cela prend une équipe
soudée car...

68. Benjamin Purgason (LinkedIn) : ici

69. “
Pour connaître le vrai succès, posez
vous ces 4 questions : pourquoi ?
pourquoi pas ? pourquoi pas moi ?
pourquoi pas maintenant ?
(James Allen)

70. Prenons le temps
◇ De se poser les bonnes questions dans notre journée de travail :
￭ Pourquoi fait-on comme cela ?
￭ Pourquoi ne pas essayer cela ?
￭ Pourquoi ne pas essayer cela maintenant ?

71. Merci!N’hésitez pas à partager votre
expérience :
◇ @lboix #confoo
Des questions?

72. Crédits
Merci également à toutes les personnes qui ont réalisé et
offert gratuitement les éléments utilisés dans cette
présentation :
◇ Template par SlidesCarnival
◇ Photographies par Pixabay