Ingénierie logicielle & cloud

Un logiciel métier se juge sur dix ans, pas sur sa démonstration. Nous voyons régulièrement des applications de trois ans que plus personne n’ose modifier : ce n’est pas un problème de technologie, c’est un problème d’architecture et de discipline d’équipe.

Nos partis pris, et ce qu’ils coûtent

Architecture à ports et adaptateurs. Le métier ne connaît ni la base de données, ni le fournisseur de modèles, ni l’interface. Changer l’un des trois ne réécrit pas les autres. Cela coûte un peu plus cher au premier jour, et beaucoup moins au troisième changement de fournisseur — c’est le calcul que nous assumons.

Multi-tenant dès la conception. Isoler les données d’une entité après coup est une refonte, jamais une évolution. Quand l’usage cible est un réseau d’entités, l’isolation se décide avant la première table.

Intégration continue avec des portes bloquantes. Analyse statique, tests, style de code. Une porte qu’on peut contourner ne protège rien : elle supprime le signal sans supprimer le problème.

Ce que nous livrons avec le code

• Une chaîne de déploiement reproductible, que votre équipe exécute sans nous.
• Les procédures d’exploitation écrites : mise en service, retour arrière, incident.
• La documentation d’architecture et les décisions techniques avec leur pourquoi — c’est le pourquoi qui manque toujours dans un projet repris.

Ce dernier point est notre condition, pas une option facturée en plus. Un logiciel que nous serions seuls à pouvoir faire évoluer nous rendrait indispensables ; c’est exactement la situation que nos clients nous demandent de résoudre.

Ce que nous ne faisons pas

Nous ne reprenons pas un système existant sans une phase d’audit facturée. Un engagement au forfait sur du code que nous n’avons pas lu est une promesse que nous ne pourrions pas tenir.