Support & maintenance

Les socles en exploitation

Odoo, Dolibarr, ERPNext, PrestaShop, Magento, SuiteCRM, Vtiger, WordPress, Drupal, Pimcore, Strapi, Matomo, Google Analytics, Microsoft 365

Nous exploitons les mêmes briques que nous intégrons : la gestion, la vente en ligne, le suivi commercial, le contenu et les référentiels, la mesure, l’environnement de travail. Les connaître en construction change ce qu’on voit en exploitation : un ralentissement de référentiel produit ou une commande bloquée dans l’orchestration se diagnostiquent d’autant plus vite qu’on sait comment ces socles sont faits.

TMA

La tierce maintenance applicative, c’est le contrat de fond : quelqu’un connaît votre système et reste disponible. Nous tenons à jour la connaissance de votre installation — ce qui a été paramétré, ce qui a été développé, pourquoi telle décision a été prise — parce que c’est cette mémoire qui manque quand un prestataire s’en va. Nous suivons les alertes, traitons ce qui remonte, et signalons ce qui va poser problème avant que ça n’en pose. Ce qui change pour vous : vous n’avez plus à réexpliquer votre système à chaque intervention.

Support & maintenance

Un incident se traite en deux temps qu’il ne faut pas confondre : rétablir le service, puis comprendre pourquoi il est tombé. Nous faisons les deux, et nous écrivons le second — sans quoi le même incident revient. Nous surveillons ce qui doit l’être, nous corrigeons, et nous vous disons ce qui s’est passé en français, pas en jargon. Nous ne promettons pas de délai contractuel : nous préférons vous dire ce que nous constatons et ce que nous faisons, plutôt que de tenir un engagement écrit qui ne dit rien de la qualité du traitement.

Évolutions

Un système utilisé bouge. Une règle change, un canal s’ouvre, une équipe se réorganise, et ce qui convenait au départ ne convient plus. Nous ajoutons les fonctions à mesure que l’usage les révèle, en discutant chaque fois de ce qui se paramètre — que vous pourrez refaire seul — et de ce qui se développe. Nous poussons volontairement vers le paramétrable : moins de code sur mesure, c’est moins de dépendance à nous. Ce qui change : le système suit votre activité au lieu de la freiner.

Mises à jour

C’est le sujet qu’on repousse jusqu’à ce qu’il devienne urgent. Nous suivons les versions des socles et de leurs composants, nous appliquons les correctifs de sécurité, et nous montons de version en vérifiant d’abord ce que le développement spécifique en pense. C’est là que la règle de construction paie : un composant greffé proprement se remonte, une fourche du produit se paie à chaque version. Ce qui change : les mises à jour redeviennent une routine au lieu d’un chantier.

Migrations

Changer de version majeure, de socle ou d’hébergeur revient toujours à la même question : les données arriveront-elles entières de l’autre côté. Nous inventorions ce qui doit passer, nous rejouons la migration sur une copie jusqu’à ce qu’elle se déroule sans surprise, nous comparons les jeux de données avant et après, et nous préparons le retour en arrière avant de basculer — pas après. La bascule elle-même est le moment le moins intéressant : tout se joue dans les répétitions.

Reprise de projet existant

Vous héritez d’un système sans documentation, sans accès complet, parfois sans savoir sur quel serveur il tourne. Nous commençons par l’inventaire : où est le code, où sont les données, qui détient les accès, ce qui a été modifié par rapport au standard. Nous documentons ce que nous trouvons, nous sécurisons ce qui doit l’être, puis nous vous disons franchement ce qui se reprend et ce qui se remplace. Il arrive que la réponse honnête soit qu’un morceau n’est pas récupérable ; nous le disons plutôt que de le maquiller.

Interconnexion de systèmes

En exploitation, ce sont les flux qui cassent en premier : un format change à une extrémité, et la synchronisation s’arrête sans que personne ne le voie pendant des jours. Nous instrumentons les échanges pour qu’un flux interrompu se signale, nous rejouons ce qui n’est pas passé, et nous reprenons la question de l’autorité sur la donnée quand un nouvel outil arrive. C’est ce qui tient l’urbanisation d’un cœur de système, l’interopérabilité clinique ou le suivi de chantier BIM dans la durée.

Hébergement

Infrastructure cloud, infrastructure dédiée, souveraineté suisse, souveraineté française

Le choix ne se fait pas sur la fiche technique, il se fait sur vos contraintes. L’infrastructure cloud convient quand la charge varie et qu’on veut pouvoir ajuster sans commander de machine. L’infrastructure dédiée s’impose quand les performances doivent être constantes ou quand un audit exige de savoir précisément où tourne quoi. La souveraineté suisse et la souveraineté française répondent à une question qui n’est pas technique : quel droit s’applique à vos données et qui peut y accéder. Nous posons cette question au début, parce qu’elle est coûteuse à traiter après.