Un système en service demande de l’entretien, pas une refonte
Un logiciel livré n’est pas fini. Il est utilisé, donc il bouge : une règle change, un canal s’ouvre, une équipe se réorganise, un composant doit être mis à jour. Sans entretien, l’écart se creuse jusqu’au jour où plus personne n’ose y toucher.
C’est à ce moment-là qu’on nous appelle le plus souvent : un système qui tourne encore, dont le prestataire d’origine n’est plus joignable, et dont la documentation n’existe pas. Nous le reprenons, nous le documentons et nous le maintenons, plutôt que de proposer de le réécrire.
Le support applicatif n’est pas qu’un numéro à appeler. C’est quelqu’un qui connaît votre installation, qui rétablit le service puis en cherche la cause, et qui vous dit ce qui s’est passé en français plutôt qu’en jargon.
Nous commençons par l’inventaire de l’existant : où est le code, où sont les données, qui détient les accès, ce qui a été paramétré et ce qui a été développé. Cet état des lieux est écrit, parce que c’est lui qui manque quand un prestataire s’en va.
Ensuite, le travail est continu plutôt que découpé en grands chantiers. Les demandes entrent par ticket, nous traitons ce qui remonte, nous signalons ce qui va poser problème, et nous distinguons à chaque fois ce qui se paramètre — que vous pourrez refaire seul — de ce qui demande du développement.
Inventaire de l’existant
Où est le code, où sont les données, qui détient les accès, ce qui a été paramétré et ce qui a été développé
Reprise et documentation
Nous écrivons ce que nous trouvons et nous sécurisons ce qui doit l’être
Maintenance en continu
Corrections, mises à jour et surveillance, les demandes suivies par ticket
Évolutions
Les fonctions ajoutées à mesure que l’usage les révèle, le paramétrage d’abord
La tierce maintenance applicative (TMA) porte sur les applications métier, les plateformes de vente en ligne, les portails et les sites de contenu : correction des anomalies, évolutions fonctionnelles, mises à jour de sécurité et montées de version.
S’y ajoutent les chantiers qui reviennent régulièrement : migration vers une nouvelle version, un nouveau socle ou un nouvel hébergeur, reprise d’un projet dont personne ne détient plus la connaissance, interconnexion avec les autres outils de la maison, et hébergement.
Les mêmes technologies, une fois qu’elles tournent
Ce que nous construisons, nous savons le maintenir — et nous reprenons aussi ce que nous n’avons pas construit. C’est même le cas le plus fréquent : un système livré il y a des années, dont le prestataire d’origine n’est plus joignable, et que plus personne n’ose toucher. L’open source y aide : le code est lisible, les données sont accessibles, rien n’est enfermé derrière une licence qui interdirait de regarder.
Les socles en exploitation
Odoo, Dolibarr, ERPNext, PrestaShop, Magento, SuiteCRM, Vtiger, sites et plateformes de contenu, 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, 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.
Le même interlocuteur qu’au premier jour, joignable.
Une situation type
Une application livrée il y a quelques années fonctionne encore, mais plus personne ne sait vraiment comment. Les correctifs s’empilent, les mises à jour sont repoussées, et chaque intervention devient plus risquée que la précédente. Nous reprenons l’existant, nous le documentons, et nous le maintenons dans la durée plutôt que de le réécrire.
Vos demandes passent par un suivi écrit : chacune est enregistrée, tracée et close. En face, un interlocuteur unique et joignable, qui connaît votre installation et à qui vous n’avez pas à la réexpliquer à chaque intervention.
La maintenance applicative couvre trois registres : corriger ce qui dysfonctionne, faire évoluer ce que l’usage réclame, et prévenir ce qui va casser — mises à jour de sécurité, montées de version, surveillance. Nous écrivons ce que nous trouvons, pour que la connaissance de votre système reste chez vous.
Combien de temps faut-il pour voir des résultats concrets ?
Les corrections de performance se voient vite ; les évolutions fonctionnelles demandent davantage. Nous cadrons l’échéance sur votre existant, une fois celui-ci repris et documenté.
Comment gérez-vous la continuité de service pendant les interventions ?
Nous travaillons par étapes, avec des environnements de test et des créneaux de maintenance convenus à l’avance.