Pour voir ce qui se passe sur le terrain pendant que ça se passe.
Une équipe part, et pendant huit heures vous décidez à l'aveugle. Où est la machine, combien il en reste, est-ce que le camion est déjà passé, pourquoi ça n'avance pas. Tout ça existe quelque part — dans un GPS, dans une caméra, dans un capteur, dans la tête de l'opérateur — mais sur cinq écrans différents, et aucun n'est devant vous.
Position, vidéo et valeurs de capteurs sur la même vue, au même moment, avec la même horloge. La valeur d'un écran d'opérateur ne vient pas de ce qu'il affiche : elle vient de ce qu'il affiche EN MÊME TEMPS.
Gros caractères, contraste fort, cibles larges, rien d'essentiel dans une couleur seule. Un opérateur regarde son écran une seconde et demie à la fois : ce qui ne se lit pas en une seconde et demie ne sera jamais lu.
L'écran continue d'afficher les dernières valeurs connues, avec leur âge affiché — et il rattrape le retard au retour du signal. Un écran qui se vide dès qu'il perd le réseau est plus dangereux qu'un écran qui n'existe pas : on lui fait confiance jusqu'au moment où on ne peut plus.
Plein soleil sur une vitre de cabine, vibration, froid, écran tactile utilisé avec des gants d'hiver. Ce sont des contraintes de conception, pas des cas limites — et c'est exactement ce qu'un logiciel dessiné dans un bureau ne prévoit jamais.
Ce qui s'affiche en direct est enregistré. Vous pouvez rejouer une journée, revenir sur une heure précise et voir exactement ce que l'écran montrait — ce qui règle une question de responsabilité sans que ce soit la parole de l'un contre celle de l'autre.
WizardOpsGestion des équipes terrainLe pointage et les bons de travail d'équipes qui ne sont jamais au bureau, en production. L'employé enregistre son temps et son travail là où il est ; le bureau voit la journée se remplir au fur et à mesure au lieu de la découvrir le vendredi. C'est la même mécanique qu'un écran d'opérateur, appliquée à des humains plutôt qu'à des machines : saisir à la source, afficher tout de suite, ne jamais dépendre du réseau pour continuer à travailler.
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.
C'est ici que ce forfait se juge. Un écran temps réel, tout le monde en vend un ; ce qui se paie, c'est ce qu'il fait quand la seconde devient difficile.
« Temps réel » ne veut pas dire rapide, ça veut dire borné : une valeur arrive avant une limite connue, sinon elle est signalée comme en retard. Un écran qui affiche une position sans dire de quand elle date ment tranquillement. Chaque valeur porte son horodatage et son âge à l'écran.
C'est le nombre de fois qu'on la redessine. Les valeurs peuvent arriver vingt fois par seconde ; l'écran, lui, se redessine à la cadence de l'affichage et pas une fois de plus. Les mises à jour sont regroupées par image — sans ça, une tablette de chantier chauffe, ralentit et vide sa batterie en deux heures.
Une position à plat suffit pour une carte, pas pour de la machinerie : l'altitude, le cap et l'attitude comptent autant que la latitude. J'ai travaillé sur du positionnement 3D air-sol en contexte de défense, où une position fausse ne se rattrape pas — et la partie difficile n'est jamais le GPS, c'est ce qu'on fait pendant les secondes où il est faux.
Envoyer un flux vidéo à un serveur pour qu'il décide et revienne, ça coûte le trajet aller-retour — trop long quand une alerte doit tomber en une demi-seconde, et impossible quand le réseau n'est pas là. La détection se fait SUR la machine ; ce qui part sur le réseau, c'est la conclusion, pas les images. C'est la contrainte avec laquelle j'ai travaillé sur de la machinerie minière autonome : sur un site minier, la couverture réseau n'est jamais une hypothèse de départ.
Deux sources qui n'ont pas la même horloge produisent un historique faux, et on ne s'en aperçoit qu'au moment où quelqu'un conteste un rapport. Les événements sont horodatés à la source, réordonnés à l'arrivée, et une donnée qui arrive en retard ne réécrit pas le présent.
L'appareil enregistre en local pendant qu'il est seul, puis renvoie l'intervalle manquant dans l'ordre. Le serveur accepte de recevoir du passé sans corrompre le présent. C'est la partie la plus ennuyeuse du travail et c'est celle qui décide si le système sert à quelque chose en janvier.
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.