IzarraX est une petite structure qui fabrique des outils Android pour des appareils gérés. Nous n'avons pas de discours à tenir sur la transformation numérique. En revanche nous avons quelques principes, et comme ce sont eux qui décident de ce que nous ajoutons et de ce que nous refusons, autant les écrire.

S'intégrer, plutôt que remplacer

Une organisation qui déploie des tablettes a déjà une console de gestion de flotte, un annuaire, des procédures, et quelqu'un qui les connaît. Arriver en proposant de tout remplacer par notre propre console, c'est demander à cette personne de jeter ce qu'elle maîtrise pour reprendre à zéro avec un fournisseur qu'elle ne connaît pas.

Nous avons donc fait l'inverse. La configuration se rédige chez nous, mais elle se distribue par votre console, sous la forme d'une configuration managée standard. Vous gardez votre outillage, vos groupes d'appareils et vos habitudes. Si vous nous quittez, vous retirez une application — vous ne démontez pas votre infrastructure.

Où sont vos données

« Souverain » est devenu un argument commercial, ce qui est dommage, parce que la question derrière est simple et concrète : où sont les données, et qui peut y accéder ?

Nos réponses sont conçues et hébergées en France. Les données d'usage remontées par les appareils décrivent l'usage des appareils — pas les personnes qui les tiennent. Nous n'avons pas de modèle économique qui dépend de la revente de quoi que ce soit, et nous n'en voulons pas : c'est plus facile de s'y tenir quand on ne l'a jamais mis dans le prévisionnel.

Petite structure, et ce que ça implique

Nous sommes petits. C'est la première objection qu'on nous oppose, et elle est légitime — autant y répondre franchement plutôt que de faire semblant d'être une grosse maison.

Ce que ça vous coûte : nous ne serons pas l'entreprise qui a déjà cent références dans votre secteur, et nous n'aurons pas un centre d'appels ouvert la nuit.

Ce que ça vous apporte : vous parlez à la personne qui écrit le code. Une demande d'évolution n'a pas trois niveaux de validation à traverser pour être entendue, et un bug reproductible n'attend pas le prochain trimestre. Quand nous nous trompons, vous le saurez par nous.

Dire non

Nous préférons refuser une fonctionnalité que la livrer à moitié. Une option qui marche dans neuf cas sur dix est pire que pas d'option du tout : elle crée une confiance que le dixième cas viendra trahir, généralement au pire moment.

Cela vaut aussi pour ce que nous acceptons de promettre en amont. Si nous ne savons pas faire quelque chose, nous le disons pendant la démonstration, pas après la signature.

Écrire la documentation avant d'en avoir besoin

Une documentation publique est le seul engagement de support qui ne dépend pas de notre disponibilité. Elle est aussi la forme la plus honnête de description d'un produit : on ne peut pas écrire un guide pas à pas pour une fonctionnalité qui n'existe pas.

C'est pour cette raison qu'elle est en accès libre, sans compte, et qu'elle décrit aussi les limites. Vous pouvez la lire avant de nous parler — et c'est exactement ce que nous vous conseillons de faire.