Plateformes logicielles sur mesure
Peu d’entreprises décident de faire développer un logiciel sur mesure. Elles décident de gérer une activité, atteignent la limite de ce qu’un outil configurable sait faire, et passent deux ans à payer des contournements avant de conclure que l’outil était le problème. On nous appelle généralement à la fin de ce parcours.
Une plateforme sur mesure vaut l’investissement quand votre façon de travailler est ce qui vous fait gagner de l’argent. Si votre tarification, votre logistique, votre circuit de validation ou votre calcul de marge vous appartiennent vraiment, un logiciel qui suppose la moyenne du secteur vous rendra discrètement moyens. Sinon, achetez l’outil. Nous vous dirons dans quel cas vous êtes avant de chiffrer.
Ce que nous construisons réellement
Nous construisons des plateformes opérationnelles : le système sur lequel une entreprise tourne, et non un site qui la décrit. Concrètement, le plus souvent Laravel ou Next.js sur AWS ou Google Cloud, dans la région il-central-1 pour les clients israéliens, avec les éléments qu’on découvre habituellement trop tard conçus volontairement dès le départ.
Le schéma
La décision qui durcit chaque semaine où on la repousse.
Les files
Pas une optimisation. La différence entre ralentir et tomber.
L’API
Conçue une fois, avant le premier consommateur.
La base de données est la décision qui reste
La conception du schéma est la seule chose qui devient plus difficile à changer chaque semaine où on la repousse. Nous y consacrons du temps tôt : quelles sont les entités réelles, où se trouve l’argent, ce qui doit être auditable, et ce qui doit survivre à une erreur. Une plateforme qui modélise correctement un client, une commande et un paiement peut absorber cinq ans d’évolutions. Une plateforme qui ne le fait pas exigera un projet de migration tous les dix-huit mois environ, et chacun vous sera vendu comme une nouveauté.
Nous utilisons du relationnel par défaut et nous sommes précis sur les endroits où nous en sortons. L’argent, les stocks et tout ce sur quoi un régulateur pourrait poser une question relèvent d’une base transactionnelle avec des contraintes qui rendent les états invalides impossibles plutôt que simplement improbables.
Les files d’attente ne sont pas une optimisation
Tout ce qui parle à un système que vous ne contrôlez pas doit se trouver derrière une file dès le premier jour : prestataires de paiement, API de transport, passerelles de messagerie, l’ERP du client. Non parce que c’est plus rapide, mais parce que c’est la différence entre une panne chez un fournisseur qui vous ralentit et une panne chez un fournisseur qui vous arrête.
Le travail est dans la gestion des échecs, pas dans la file. Ce qui est rejoué, combien de fois, avec quel délai, ce qui peut être exécuté deux fois sans danger, et ce qui doit être traité par un humain qui devra comprendre ce qui s’est passé six heures plus tôt. L’idempotence est une propriété de conception, pas quelque chose qu’on ajoute pendant un incident.
Une API se conçoit une fois
Toutes les plateformes que nous construisons finissent par avoir un autre système qui leur parle, généralement plus tôt que prévu : une application mobile, un partenaire, un outil de reporting, une fonctionnalité IA. Nous concevons la surface d’API comme un produit dès le début, avec le versionnement et l’authentification décidés avant le premier consommateur, parce que les ajouter après casse ceux qui sont déjà connectés.
Ce que cela coûte à exploiter
Nous chiffrons et concevons pour le coût d’exploitation, pas seulement pour la construction. Une plateforme coûteuse à exploiter est une plateforme qu’on vous demandera de remplacer, et les décisions qui font cette facture sont architecturales : ce que vous gardez en mémoire, à quel point le système bavarde avec lui-même, si vous avez dimensionné pour votre heure de pointe ou pour votre moyenne, et quelle part du trafic n’avait jamais besoin d’atteindre l’application.
Nous préférons livrer quelque chose de modeste qui coûte très peu à exploiter et peut grandir, plutôt que quelque chose d’impressionnant qui démarre avec une facture que personne n’avait budgétée. Le cache, le CDN et la conception des requêtes font davantage pour la vitesse et pour le coût que l’ajout de capacité, et ils continuent à le faire à mesure que vous grandissez.
Comment se déroule le travail
Une mission commence normalement par un cadrage court et payant. Nous regardons ce que vous avez, ce que cela coûte, ce qui casse, et ce que vous cherchez réellement à obtenir. Le résultat est une architecture, un plan par phases et une estimation, rédigés de façon que vous puissiez les confier à un autre prestataire si vous le vouliez. Cela arrive parfois et nous préférons que cela arrive plutôt que d’enfermer quelqu’un dans un document que nous seuls savons lire.
Ensuite nous construisons par phases qui se terminent chacune par quelque chose d’utilisable. La première livraison est volontairement étroite : un vrai processus, en production, avec de vrais utilisateurs. Une plateforme qui atteint la production en huit semaines et grandit vaut mieux qu’une plateforme complète au bout d’un an, parce que la seconde est complète selon des hypothèses que personne n’a testées.
Nous restons ensuite. L’équipe qui a conçu le schéma est celle qui reçoit l’alerte à deux heures du matin, ce qui se révèle une contrainte remarquablement efficace sur les décisions de conception.
La technologie, et pourquoi
Nous choisissons par projet et non par habitude. Laravel et PHP quand le travail est opérationnel et durable, Next.js et React quand l’interface est la partie difficile, sur AWS ou Google Cloud. Ce que nous ne ferons pas, c’est choisir quelque chose parce que c’est nouveau.
Ce que ces choix ont en commun, c’est un large vivier de développeurs et un horizon de support long, pour qu’un développeur arrivé en troisième année puisse lire le code écrit la première. Nous optimisons pour la décennie, pas pour la démonstration.
Nous exploitons nos propres produits sur la même pile, dont irua.app et wagate.app, ce qui veut dire que les décisions d’exploitation que nous recommandons sont celles avec lesquelles nous vivons.
À voir aussi
Les plateformes sont rarement isolées. La plupart des nôtres impliquent aussi de l’intégration avec des logiciels déjà en place, et de plus en plus des fonctionnalités IA construites sur les données que la plateforme collecte. Si la plateforme est une boutique, voir l’ingénierie e-commerce.
Questions fréquentes
Combien de temps prend une plateforme sur mesure ?
Une première mise en production prend généralement huit à seize semaines, selon le nombre de systèmes externes à interfacer. Ce sont les intégrations, pas les fonctionnalités, qui font bouger ce chiffre. Un remplacement complet s’étale habituellement sur six à dix-huit mois par phases, avec quelque chose d’utilisable en production tout du long.
Sommes-nous propriétaires du code ?
Oui. Le code, les définitions d’infrastructure et la documentation sont à vous, dans votre dépôt, et vous pouvez les emporter ailleurs. Nous ne construisons pas sur une couche propriétaire que nous seuls saurions maintenir.
Et si nous avons déjà un système ?
L’essentiel de notre travail porte sur des systèmes existants. Tout remplacer d’un coup est presque toujours la mauvaise décision : nous posons généralement la nouvelle plateforme à côté de l’ancienne, migrons un processus à la fois, et laissons les deux tourner jusqu’à ce que l’ancienne n’ait plus rien à faire.
Pouvez-vous travailler avec nos développeurs ?
Oui, et cela arrive souvent, y compris en tant qu’équipe technique derrière une agence qui garde la relation client. Nous sommes également à l’aise pour tout transmettre une fois la plateforme stabilisée.
Que se passe-t-il si nous arrêtons de travailler ensemble ?
Vous gardez tout et nous documentons la reprise correctement. Nous n’avons aucun intérêt à des clients qui restent parce que partir est compliqué.
Plus de services
La suite
Dites-nous ce que vous construisez, ou ce qui casse.