03 Notre méthode

La deuxième année est le vrai test.

N'importe quoi peut être fait pour tenir jusqu'au lancement. Ce qui compte, c'est de savoir si on peut encore le modifier sans risque une fois l'enthousiasme retombé et les personnes qui l'ont construit parties.

Démarrer un projet

Pourquoi un logiciel se dégrade

Un logiciel ne s'use pas comme un objet physique. Il se dégrade parce que le monde autour de lui bouge — les dépendances vieillissent, les navigateurs changent, les correctifs de sécurité tombent, les réglementations évoluent, et l'activité demande des choses que personne n'avait imaginées au départ. Laissé sans surveillance, un système qui fonctionne devient discrètement un système à risque.

Le schéma habituel sur ce marché, c'est livraison puis disparition. Un système est remis, l'équipe passe à autre chose, et le client se retrouve avec quelque chose que personne ne comprend. Chaque changement devient une négociation avec qui que ce soit de disponible et de bonne volonté. Les coûts montent, la confiance baisse, et finalement quelqu'un suggère de tout reconstruire depuis zéro.

Nous fonctionnons autrement. Les ingénieurs qui construisent votre système continuent de l'entretenir — dépendances mises à jour, performance surveillée, problèmes corrigés avant que vous ne les remarquiez. Il n'y a ni passation à des inconnus ni remise à niveau, parce que ceux qui ont pris les décisions sont toujours ceux qui les appliquent.

LAUNCHEDYEAR 1YEAR 2YEAR 3SAME THREE ENGINEERSSTILL LOOKING AFTER IT

Comment savoir si c'est votre problème

Chaque projet commence par un appel de cadrage
  • Une seule personne comprend une partie critique de votre système
  • Personne n'a mis à jour les dépendances depuis plus d'un an
  • De petits changements sont chiffrés comme s'ils étaient importants
  • Votre équipe de développement d'origine est injoignable
  • Il n'existe aucune documentation sur la façon dont tout est déployé
  • Quelqu'un a suggéré de tout reconstruire plutôt que de le modifier

Comment nous y parvenons

SECURITY PATCHESDEPENDENCY UPDATESPERFORMANCE WATCHFIXES BEFORE YOU ASKCONTINUOUS — NOT A SUPPORT QUEUE
Une équipe qui reste
Les ingénieurs qui ont construit votre système continuent de le maintenir. Pas de remise à niveau, pas de transmission à des inconnus, pas de redécouverte de décisions prises deux ans plus tôt.
Des standards qui tiennent
Frameworks conventionnels, typé de bout en bout, infrastructure versionnée dans votre dépôt — pour que le système reste aussi propre en année trois qu'à la semaine de la livraison.
Suivi continu, pas de tickets
Dépendances mises à jour, performance surveillée, problèmes corrigés avant que vous les remarquiez. La maintenance est un travail continu, pas quelque chose qu'on vous fait réclamer.

Ce que coûte l'inaction

01

Le changement devient une négociation

Quand personne dans l'équipe actuelle n'a construit le système, chaque demande commence par des semaines de redécouverte. Une petite fonctionnalité est chiffrée comme une grande, parce que l'essentiel de l'effort consiste à comprendre l'existant.

02

La dette de sécurité s'accumule en silence

Les dépendances non corrigées ne préviennent pas. Elles restent silencieuses jusqu'à ce qu'une vulnérabilité devienne publique — et vous découvrez alors que vous étiez exposés depuis des mois.

03

La question de la refonte revient

Un système que personne n'entretient finit par devenir un système que personne ne veut toucher. La solution proposée est toujours une reconstruction — payer deux fois pour un logiciel que vous possédez déjà.

04

Le savoir part avec les gens

Quand l'équipe qui l'a construit se disperse, la logique derrière chaque décision part avec elle. Il reste du code qui fonctionne pour des raisons que plus personne ne sait expliquer — ce qui est dangereux à modifier.

WITHOUT ITWITH ITCOST OVER TIME

Les questions qu'on nous pose

Que couvre vraiment la maintenance ?
Les mises à jour de dépendances et de sécurité, la surveillance et le traitement de ce qu'elle révèle, le travail de performance à mesure que l'usage grandit, la correction des défauts, et l'adaptation du système à l'évolution de votre activité. C'est un travail continu, pas une file de tickets de support.
Et si nous voulons travailler avec quelqu'un d'autre plus tard ?
Oui, et tout est pensé pour que ce soit réellement possible — vos dépôts, vos comptes, vos données, des frameworks conventionnels qu'une autre équipe peut lire. Nous préférons mériter le travail chaque année plutôt que de le retenir en otage.
Pouvez-vous reprendre un système construit par quelqu'un d'autre ?
Souvent, oui. Nous commençons par un audit — architecture, dépendances, sécurité, déploiement — et vous donnons une évaluation honnête de ce que coûte la maintenance face à ce que coûterait un remplacement. Parfois, le système est en meilleur état que ce que vous craigniez.
Combien de temps restez-vous impliqués ?
Aussi longtemps que vous le souhaitez. Tout l'intérêt de la deuxième et de la troisième année, c'est que le système continue de s'améliorer au lieu de se dégrader — et cela ne fonctionne que si ce sont les mêmes personnes qui restent dessus.
Qu'est-ce qui rend un code maintenable, en pratique ?
Des frameworks conventionnels plutôt que des solutions maison ingénieuses, des types qui documentent l'intention, des tests qui permettent de changer les choses en toute sécurité, une infrastructure définie comme du code, et des décisions consignées par écrit. Rien d'exotique — c'est de la discipline appliquée avec constance.

La deuxième année est le vrai test.

Dites-nous où ça bloque. Un appel court, une réponse honnête sur si nous sommes la bonne équipe, et un périmètre que vous pouvez chiffrer.

Démarrer un projet hello@elixiria.ma
enfrar