Garder l’ownership de son système, même sans être technique

Beaucoup de systèmes fonctionnent très bien — jusqu’au jour où il faut en changer une pièce. Changer de prestataire, d’hébergeur, d’outil. C’est là qu’on découvre qui possède vraiment le système : vous, ou la personne qui l’a construit.

Le test de la sortie

La question la plus honnête à poser à un prestataire n’est pas « que savez-vous faire ? » mais « si on arrête de travailler ensemble demain, qu’est-ce que je garde ? ». Le code, les accès, les données, la documentation, la capacité de faire tourner le système ailleurs. Si la réponse est floue, l’ownership est flou.

Le test de l’explication

Vous n’avez pas besoin de comprendre chaque ligne de code. Vous avez besoin qu’on puisse vous expliquer, simplement, ce que fait le système, où vivent vos données et pourquoi les choix techniques ont été faits. Un système qui ne peut pas être expliqué simplement est soit trop complexe, soit volontairement opaque. Les deux sont des problèmes.

Le test de la dépendance

Combien de briques de votre système dépendent d’un service que vous ne contrôlez pas — et que se passe-t-il si l’une d’elles disparaît ou triple ses prix ? Chaque dépendance n’est pas mauvaise en soi ; une dépendance non identifiée et non remplaçable, si.

L’ownership n’est pas une question de compétence technique. C’est une exigence à poser dès le départ — et un système sobre, lisible et documenté est précisément ce qui la rend possible.