Pour que vos systèmes cessent de s’ignorer et de vous faire ressaisir.
Chaque logiciel de votre entreprise a raison tout seul. C'est ensemble qu'ils ont tort. La commande existe dans l'un, la facture dans l'autre, l'inventaire dans un troisième, et quelqu'un passe ses lundis matin à exporter un fichier pour l'importer ailleurs. Ça marche — jusqu'à la semaine où cette personne est malade, ou jusqu'au transfert qui échoue sans que personne ne le sache.
Avant d'écrire une ligne, on décide pour chaque donnée quel système a raison. Sans cette décision, une passerelle ne règle rien : elle propage le désaccord plus vite. C'est la partie du travail qui se fait avec vous, pas devant un écran.
Certaines données peuvent attendre la nuit, d'autres doivent partir dans la minute. Les deux coûtent le même travail à bâtir et pas le même à faire tourner — on choisit en fonction de ce que ça change pour vous, pas de ce qui fait moderne.
Le réseau coupe, l'autre système redémarre, une valeur est refusée : ça arrive, tout le temps. Ce qui a échoué est mis de côté, réessayé, et rejouable à la main — sans jamais créer la commande en double. C'est la différence entre une passerelle et un script.
Ce qui est passé, quand, et ce qui a échoué — en français, pas en codes d'erreur. Et une alerte quand quelque chose est bloqué depuis trop longtemps. Une passerelle silencieuse qui a cessé de fonctionner il y a trois semaines est pire qu'une passerelle absente.
Beaucoup de logiciels d'entreprise n'ont aucune porte d'entrée prévue. Il en reste toujours une : un dépôt de fichiers, un export planifié, une base en lecture seule, parfois l'écran lui-même. C'est moins élégant et c'est parfaitement fonctionnel — et c'est souvent le seul chemin qui existe.
Faire parler deux systèmes qui ne se connaissent pas, c'est le métier que je faisais avant d'écrire du logiciel. Un réseau télécom, ce n'est que ça : des équipements de fabricants différents, d'époques différentes, qu'il faut convaincre de s'entendre — et quand il n'y a pas de norme commune, on trouve le chemin qui existe. C'est exactement le même problème qu'un ERP de 2009 qui doit parler à une application de 2026, et c'est pour ça que je ne recule pas devant.
Le travail derrière la citation →Personne n'écrit cette section, et c'est exactement pour ça qu'une PME a peur d'un devis de logiciel : ce n'est pas le montant qui inquiète, c'est de ne pas savoir où il s'arrête. Voici où il s'arrête.
Tout ce qui précède a une fin : un périmètre, un prix, une date de livraison. Ceci n'en a pas. C'est compris avec les six forfaits, ça ne se facture pas à part, et ça ne dépend pas de la taille du contrat.
Vous m'appelez. Jour, nuit, fin de semaine. Pas de formulaire, pas de premier niveau qui vous demande d'avoir redémarré, pas de numéro de dossier. Quand quelque chose brûle, vous avez au bout du fil la personne qui a écrit le code — c'est la seule qui peut répondre vite, parce qu'elle sait déjà où regarder.
Comprendre comment un logiciel se fait attaquer change la façon de le concevoir au départ — pas la façon de le rafistoler à la fin. Je fais du test d'intrusion : je cherche les failles de vos systèmes avant que quelqu'un d'autre les trouve, et comme c'est moi qui les ai bâtis, je sais où sont les endroits laids.
Une entreprise frappée prend ses pires décisions dans les six premières heures, parce que personne autour d'elle ne sait quoi faire et que tout le monde parle en même temps. On contient d'abord, on établit ensuite ce qui est réellement touché — c'est presque toujours moins grave que ce que la note d'écran prétend — et on récupère ce qui est récupérable. Vous parlez à votre assureur et aux autorités avec des faits, pas avec de la panique.
Les demandes de rançon se font en cryptomonnaie, et c'est exactement là qu'une entreprise avance à l'aveugle : d'où vient l'adresse, ce qui est traçable, ce que la police peut réellement faire, et surtout ce que payer ne règle pas — parce que payer ne rend pas les données et ne referme pas la porte d'entrée. Je vous explique ce que vous avez devant les yeux. La décision reste la vôtre et celle de votre assureur, mais elle se prend en sachant.
Une sauvegarde qu'on n'a jamais restaurée n'est pas une sauvegarde, c'est une croyance — et c'est le jour du sinistre qu'on découvre laquelle des deux on avait. Celles des systèmes que je livre sont testées en restaurant pour vrai, et vous savez combien de temps ça prend AVANT d'en avoir besoin.
Une passerelle, ça se juge le jour où elle échoue, pas le jour où elle marche. Voici ce qui se passe ce jour-là.
Chaque transfert porte une clé qui lui est propre. Rejoué deux fois, il ne produit pas deux commandes : le second passage reconnaît le premier et ne fait rien. Sans ça, le seul moyen sûr de réparer une panne est de ne rien rejouer du tout — et donc de perdre ce qui est tombé.
Les transferts passent par une file avec des réessais espacés dans le temps et une limite. Ce qui échoue définitivement va dans une file d'échecs, visible, au lieu de disparaître dans un journal que personne ne lit. Un script en tâche planifiée n'a ni mémoire ni patience.
CSV avec des accents dans un encodage des années 90, fichiers à position fixe, XML d'un dialecte maison, dates en trois formats dans la même colonne. C'est la réalité de l'échange entre systèmes d'entreprise, et un connecteur du commerce s'arrête net à la première irrégularité.
Lecture directe sur une base en lecture seule, dépôt de fichiers surveillé, export planifié récupéré automatiquement, et en dernier recours l'écran lui-même. Ce dernier chemin est fragile et je le dis avant de le prendre — mais entre un chemin fragile et pas de chemin, le client choisit rarement rien.
Clés, mots de passe et jetons d'accès dans des variables d'environnement, jamais dans le dépôt. Une clé d'API écrite dans un fichier versionné est publique le jour où quelqu'un clone le dépôt, et elle le reste dans l'historique même après avoir été effacée.
Un tableau de ce qui tourne, de ce qui traîne et de ce qui a échoué, et une alerte automatique quand un flux est bloqué au-delà de son délai normal. Vous n'apprenez pas une panne d'intégration par un client fâché.
Rien ici n'est une promesse de brochure : c'est la façon dont je bâtis, et vous pouvez me la faire vérifier par quelqu'un.
Pas besoin d'un cahier des charges ni du bon vocabulaire. Une ou deux phrases sur ce qui est lent, manuel ou impossible en ce moment suffisent.
Au téléphone, avec moi — pas avec un vendeur. On cherche ce qu'il faut vraiment bâtir, et surtout ce qu'il ne faut pas bâtir.
Un montant, et la liste de ce qui est livré pour ce montant. Il ne bouge plus ensuite. Rien à payer tant que vous n'avez pas dit oui à cette liste.
Pas une maquette à commenter : du logiciel que vous ouvrez et que vos gens utilisent pour vrai, le plus tôt possible.
C'est en s'en servant qu'on voit ce qui accroche. Ce qui accroche se corrige avant qu'on bâtisse la suite par-dessus.
Web, App Store, Google Play, votre serveur — selon le projet, et c'est moi qui le fais. Le code vous appartient, et c'est encore moi qui réponds quand vous appelez ensuite.
Dites-moi laquelle. Je vous dis ce que je bâtirais, combien de temps ça prend et ce que ça coûte — sans engagement, et sans jargon.