Maintenance et support après livraison
Un système doit rester sûr, stable et compréhensible après la mise en production. Nous définissons la maintenance comme un périmètre de responsabilité clair — et non comme une disponibilité indéfinie.
Quand cette approche est pertinente
- Un système est en production et nécessite un suivi technique continu.
- Les mises à jour de sécurité et la gestion des dépendances demandent une attention régulière.
- Des incidents doivent être corrigés rapidement sans compromettre l'exploitation.
- De nouvelles fonctionnalités doivent être ajoutées progressivement sans déstabiliser le système.
- La supervision et les sauvegardes ne sont pas ou insuffisamment en place.
- L'équipe interne n'a pas la capacité ou l'expertise pour la maintenance technique continue.
Périmètre de la prestation
- Supervision de l'exploitation et alertes
- Sauvegardes régulières et tests de restauration
- Gestion des incidents et correction des anomalies
- Mises à jour des dépendances et de sécurité
- Améliorations et ajustements mineurs
- Feuille de route fonctionnelle et évolution priorisée
- Modèle de temps de réponse et processus d'escalade
- Rapports de statut réguliers
- Mise à jour de la documentation lors des changements
Applications typiques
- Maintenance continue d'une application développée par Base 17
- Reprise de la maintenance d'un système existant après évaluation technique
- Mises à jour de sécurité et supervision pour des applications web en production
- Extension progressive d'un système après la livraison initiale
- Support aux équipes internes pour les questions techniques et les incidents
- Préparation et exécution de mises à niveau planifiées
Processus de développement
Le processus est volontairement simple et transparent : périmètre clair, phases courtes, une version utilisable. Cela réduit le risque et reste aligné sur le fonctionnement réel.
Recueil des besoins
Nous définissons ensemble ce que le système doit résoudre. L'objectif est une première version utilisable — un minimum fiable au quotidien — pas tout d'un coup.
User stories, cas d'usage et croquis
Les besoins sont découpés en petites parties : qui fait quoi, pourquoi, avec quel résultat. Au besoin, des croquis de flux ou wireframes simples alignent les attentes.
Estimation du temps et du coût
Chaque unité de travail reçoit une estimation réaliste. Leur somme donne durée et coût. Les besoins peuvent évoluer — avec un impact clair sur le délai et le prix.
Backlog de priorités
Avant le développement, les éléments convenus entrent dans une liste de priorités : fonctions, intégrations, corrections et tout le nécessaire pour une livraison viable.
Définition des phases
Le travail est découpé en phases courtes (généralement une à deux semaines). Chaque phase a un périmètre convenu et un objectif vérifiable.
Itérations et revues
En fin de phase, nous revoyons l'avancement, corrigeons les hypothèses et choisissons le prochain lot. Vous gardez le contrôle de la direction.
Mise en production
Quand une version est prête : préparation des données, contrôles en conditions réelles et accompagnement aux premiers usages.
Qualité et sécurité
- Supervision proactive plutôt que correction réactive
- Processus d'incident et voies d'escalade documentés
- Mises à jour de sécurité selon un processus documenté
- Sauvegardes testées et restauration traçable
- Changements versionnés et documentés
- Aucun chiffre SLA publié sans accord contractuel
Ce dont nous avons besoin de votre part
- Un accès au système, à l'infrastructure et à la documentation pertinente
- Un interlocuteur pour la priorisation et la validation des changements
- Des informations sur les évolutions métier prévues qui concernent le système
- Une définition claire des temps de réponse et des attentes de disponibilité
- Une validation écrite des changements importants
- Des revues régulières du périmètre de maintenance