Service:Service

Conseil & accompagnement

Coaching d'équipes internes, mise en place de CI/CD, DevOps, culture qualité et pratiques d'ingénierie.

Ce que nous livrons
  • Pipelines CI/CD
  • Environnements automatisés
  • Métriques DORA
  • Coaching techlead
CI/CDDevOpsCoaching

On nous appelle rarement pour installer une chaîne d'intégration continue. On nous appelle parce que les livraisons font peur, qu'elles ont lieu le soir, et qu'elles mobilisent trois personnes pendant deux heures. La chaîne de déploiement est l'outil ; ce qu'on vient réparer, c'est le rapport de l'équipe à sa propre mise en production.

Cette prestation se déroule à l'intérieur de vos équipes et pas à côté. Nous n'installons pas un système que vous découvrirez à la fin. Nous le construisons avec les personnes qui vont l'exploiter, dans leurs outils, avec leurs contraintes, y compris celles qui nous semblent discutables et qui ont souvent une bonne raison d'exister.

Comment nous travaillons

Une chaîne de déploiement qu'on ose lancer

Le critère de réussite n'est pas technique : c'est qu'un développeur arrivé depuis trois semaines livre en production un mardi après-midi, seul, sans demander l'autorisation à personne. Tout ce qu'on met en place sert cet objectif : tests automatiques rapides, environnements reproductibles, retour arrière en une commande, et déploiement progressif quand l'enjeu le justifie.

Nous accordons une attention particulière à la durée. Une chaîne qui prend vingt-cinq minutes n'est pas lancée à chaque commit, donc les commits s'accumulent, donc les livraisons grossissent, donc elles font peur. C'est un cercle qu'on casse par le bas, en descendant sous les dix minutes, quitte à découper la chaîne en étapes dont seule la première bloque.

Les métriques DORA, utilisées correctement

Quatre indicateurs : la fréquence de déploiement, le délai entre un commit et sa mise en production, le taux d'échec des changements, et le temps de rétablissement après incident. Leur force est qu'ils se contredisent deux à deux. On ne peut pas améliorer la vitesse en cassant la stabilité sans que les deux autres le montrent immédiatement.

Nous insistons sur un point : ces chiffres mesurent un système, jamais une personne. Le jour où ils entrent dans l'évaluation individuelle d'un développeur, ils deviennent faux en trois semaines, parce que chacun apprend à les optimiser. Nous les affichons pour l'équipe, discutés par l'équipe, et nous refusons les demandes de les remonter par individu.

Coacher un tech lead, pas le remplacer

Un développeur promu tech lead se retrouve du jour au lendemain à devoir arbitrer, dire non, et découper du travail pour d'autres, sans que personne ne lui ait jamais montré comment. Le réflexe est de continuer à coder, parce que c'est ce qu'il sait faire, et l'équipe se retrouve sans direction technique tout en ayant un titre pour le prétendre.

Nous accompagnons ces personnes sur trois à six mois, à raison de quelques heures par semaine. On travaille des choses concrètes : comment découper une fonctionnalité, comment mener une revue sans braquer, comment défendre un chantier technique devant une direction qui n'en voit pas le retour. L'objectif est qu'à la fin nous soyons devenus inutiles, et nous préférons le dire dès le premier jour.

Ce qui amène ici

  • Les mises en production ont lieu le soir ou le week-end, et mobilisent plusieurs personnes.
  • Un nouvel arrivant met plus d'une semaine à obtenir un environnement de développement qui fonctionne.
  • Vous venez de nommer un tech lead qui n'a jamais encadré et qui code encore à plein temps.
  • Personne ne sait combien de temps s'écoule entre un développement terminé et sa disponibilité pour les utilisateurs.

Quand ce n'est pas la bonne prestation

Si l'attente est que nous arrivions, installions un outillage et repartions en trois semaines, cela ne marchera pas. Ce genre de mission laisse derrière elle une chaîne que personne ne sait réparer au premier incident, et qui sera contournée au deuxième. Comptez trois mois minimum avec une disponibilité réelle de vos équipes. Si ce temps n'est pas disponible, mieux vaut décaler la mission que la rater.

Nous le disons avant de commencer, pas après.

Qualité mesurée

Tests automatisés écrits pendant le développement, pas après. Revue de code obligatoire avant toute fusion, y compris sur les correctifs d'une ligne. Analyse statique branchée sur la CI : si la couverture baisse ou qu'une vulnérabilité connue apparaît, la chaîne s'arrête et personne ne passe outre.

Livraison continue

Un environnement de recette déployé à chaque fusion, une démo à la fin de chaque itération, et un tableau d'avancement que vous consultez quand vous voulez sans avoir à le demander. Les mauvaises nouvelles arrivent tôt, quand il reste du temps pour décider quoi faire.

Transfert de savoir

Nous partons du principe que vous reprendrez la main. Les décisions d'architecture sont écrites et datées, la documentation vit dans le dépôt à côté du code, et vos développeurs travaillent en binôme avec les nôtres s'ils le souhaitent. À la fin, le code, les accès et l'historique vous appartiennent.

Aller plus loin:Service[3]

Autres services

Un projet en tête ? Donnons-lui vie.

Dites-nous ce que vous cherchez à construire ou à reprendre. Réponse sous 24 heures ouvrées, sans engagement, et un avis franc sur la faisabilité même si la réponse ne nous arrange pas.