Dix mandats, un SLA de trente minutes

Graphem Solutions vend de la confiance. Le cabinet pilote en permanence plus de dix mandats simultanés — SaaS, e-commerce, intégration CRM, mobile, hébergement — et la phrase qui décroche les clients est un SLA de réponse de trente minutes sur tout entrant. Ce SLA n’est pas une ligne marketing. C’est la contrainte opérationnelle dans laquelle tout le reste doit tenir.

J’y suis arrivé comme assistant CTO en septembre 2025, et j’ai été promu chef de projet technique quatre mois plus tard. Voici ce que je fais ici.

Ce qui a changé en quatre mois

La promotion n’était pas un changement de titre. Le mandat s’est élargi : du soutien au CTO sur les programmes à la propriété du cadrage technique, de l’estimation, et de la coordination d’équipe sur les programmes full-stack que pilote le cabinet. Je me tiens entre l’ingénierie — où le travail se fait — et le côté business, où les feuilles de route se négocient contre des deadlines qui ne bougent pas.

Ce qui n’a pas changé : j’écris encore du code quand une question épineuse l’exige, je revois encore l’architecture, je ferme encore les boucles que personne d’autre n’a le temps de fermer. Ce qui a changé : dix choses se passent maintenant en parallèle au lieu de trois, et la qualité de mes notes est la différence entre tenir le SLA un mardi matin et le rater.

Coordonner dix choses à la fois

L’équipe avec laquelle je travaille fait cinq à dix ingénieurs et designers, selon ce qui est en cours. Les stacks sont hétérogènes — Laravel et Vue côté sur-mesure, Node là où ça convient, WordPress et Shopify et WooCommerce côté produits packagés, HubSpot pour les mandats d’intégration CRM. Clients PME et grands comptes au Canada et aux États-Unis, chacun avec sa propre cadence.

Le SLA de trente minutes signifie que le système doit être conçu pour ça. Concrètement : règles de triage qui routent les entrants vers le bon ingénieur sans réunion ; statut précis à la demi-heure ; et une posture où chaque mandat actif a un propriétaire nommé capable de répondre à un client dans son langage — vente, marketing, exécutif, technique — sans escalade.

Dix mandats à ce tempo, c’est un problème de coordination, pas d’ingénierie. Le travail d’ingénierie est réel mais c’est la moitié plus facile. La moitié plus dure, c’est s’assurer que rien ne tombe entre les coutures.

La documentation comme ingénierie

Le levier qui a composé le plus vite est la documentation interne et les standards de gestion des connaissances. À mon arrivée, l’onboarding était tribal — les nouveaux ingénieurs apprenaient en s’asseyant à côté des anciens. Les passations entre ingénierie, design, ventes et direction perdaient du temps à chaque couture.

J’ai écrit les standards qu’on utilise aujourd’hui : comment cadrer une estimation, comment structurer une proposition technique, comment documenter une décision d’architecture, comment passer une fonctionnalité, comment clore un mandat. Rien de ça n’est neuf comme idée. Le travail, c’est de le rendre cohérent, de le rendre le chemin de moindre résistance, et de s’assurer que les gens l’utilisent vraiment.

L’onboarding s’est compressé. Les frictions de passation sont tombées. Le SLA de trente minutes est devenu plus facile à tenir non pas parce que l’ingénierie est devenue plus rapide, mais parce que les coutures sont devenues plus lisses.

Le travail continue. Chaque trimestre, le cabinet prend plus de programmes, la surface s’élargit, et la discipline opérationnelle qui tient l’ensemble doit s’élargir avec. C’est le poste.