Chaque mission commence par la même question : où voulez-vous arriver, et qu’est-ce qui vous en empêche ? La plupart de nos clients ont de vraies échéances, de vraies contraintes et une activité qui ne peut pas s’arrêter pendant qu’on remplace le logiciel. Le travail est donc organisé autour du résultat que vous visez, pas autour des heures facturables.
Trois façons de faire appel à nous. La plupart des clients commencent par l’une et évoluent vers une autre.
Un leadership technique senior sans recrutement à temps plein, pour les équipes qui ont besoin d’un cap, pas seulement de bras.
Des ingénieurs seniors opérationnels dès le premier jour, qui laissent votre équipe plus solide qu’ils ne l’ont trouvée.
Analyse métier et cadrage pour transformer une idée brute en un plan délimité, chiffré et réalisable.
Ateliers privés sur l’architecture, la planification de sprint et l’estimation, le cadrage et la feuille de route, les standards d’ingénierie, .NET MAUI et la migration Xamarin, Bluetooth LE et l’exécution en arrière-plan, le .NET moderne et l’IA. Construits à partir de votre propre code et animés par les auteurs des bibliothèques présentes dans votre fichier projet.
La plupart des projets d’IA calent bien avant que le modèle ne pose problème. Les données nécessaires dorment sur un appareil, dans un système hérité ou dans un format que rien ne peut interroger. Nous traitons tout le parcours : de l’endroit où les données sont créées jusqu’au point où un assistant peut les utiliser en toute sécurité.
La moitié ingrate : acheminer vos données de leur lieu de création jusqu’à un endroit accessible à un modèle, sans rien perdre en route.
Exposer vos systèmes à un assistant de façon délibérée plutôt que par copier-coller, avec des limites claires sur ce qu’il peut voir et faire.
Assistants, voix et automatisation intégrés à l’application que vos utilisateurs ont déjà ouverte, au lieu d’un onglet de plus à ne pas oublier.
L’échec vient rarement de la technologie. Il vient d’un déploiement que personne n’a mesuré, de données parties là où elles n’auraient pas dû aller, ou d’un processus discrètement confié à un modèle dont personne n’est responsable. Voici les règles que nous appliquons à chaque mission d’IA.
Un processus dont vous pouvez réellement mesurer le coût, validé avant toute extension. Les déploiements à l’échelle de l’entreprise sur une intuition, c’est ainsi que les budgets IA se font annuler.
Ce qui sort de votre réseau, ce sur quoi un fournisseur peut entraîner ses modèles, et où les données réglementées ont le droit de résider : décidé délibérément et consigné par écrit avant le premier prompt.
Tout ce qui touche à l’argent, à la sécurité ou à un client reste soumis à une validation humaine, et le système enregistre qui a décidé quoi. L’IA rédige ; votre équipe signe.
Évalué sur de vrais cas issus de votre activité, pour connaître la précision avant que vos clients ne la découvrent, et pour détecter le moment où le modèle commence à dériver.
Le modèle est une pièce remplaçable. Vos données, vos outils et vos évaluations sont le véritable actif, et ils restent portables la prochaine fois que ce marché bougera.
Certains processus ne devraient pas être automatisés, et certains problèmes se règlent à moindre coût avec un meilleur écran. Nous vous le dirons avant que vous n’ayez payé pour l’alternative.
Un bref état des lieux des données que vous détenez déjà, de celles que vous jetez, et de ce dont un modèle aurait réellement besoin pour répondre aux questions qui comptent pour votre activité. Cela prend en général deux semaines et débouche sur un plan chiffrable, avec souvent un constat utile : la première phase relève de la tuyauterie, pas de l’IA.
Une liste volontairement courte. Ce sont les domaines où nous comptons réellement parmi les personnes que vous voudriez voir sur le problème : le mobile, les objets connectés et les services cloud qui les relient.
Applications .NET MAUI, iOS et Android en production, et migrations Xamarin → MAUI, y compris l’arrière-plan, le hors-ligne et le cycle de vie que la plupart des équipes ratent. Nous travaillons avec l’équipe .NET MAUI de Microsoft depuis les débuts de MAUI.
BLE central et périphérique, parcs d’appareils et intégration matérielle. Nous avons écrit les bibliothèques que le secteur utilise pour cela.
Géolocalisation, géorepérage et télématique pour les véhicules et les équipes qui travaillent là où la connectivité n’est pas garantie.
Applications Apple Watch, Wear OS, CarPlay et Android Auto qui prolongent votre application mobile jusqu’au poignet et au tableau de bord, pensées pour un coup d’œil ou une commande vocale, pas pour un écran de téléphone rétréci. Le lien entre le téléphone et la montre repose sur une bibliothèque que nous avons écrite.
Les services et API ASP.NET Core derrière l’appareil : conçus pour se déployer proprement, rester peu coûteux à exploiter et tenir la charge quand toute la flotte remonte ses données en même temps.
Migrer des applications .NET Framework héritées et des bases de code mobiles vieillissantes vers les plateformes actuelles, sans interrompre les livraisons.
Vingt-cinq ans dans des activités où le logiciel doit résister à l’épreuve du réel : camions, entrepôts, chantiers, services hospitaliers et files d’appels.
Les migrations de Xamarin vers .NET MAUI sont l’une de nos spécialités, tout comme .NET MAUI lui-même. Nous travaillons avec l’équipe .NET MAUI de Microsoft depuis les débuts de MAUI, et nos bibliothèques ont contribué à façonner l’écosystème sur lequel reposent aujourd’hui les applications MAUI.
Le support de Xamarin a pris fin en mai 2024. Ce qui bloque ces migrations, ce n’est presque jamais la conversion de l’interface, c’est la liste des dépendances. Chaque plugin abandonné derrière le Bluetooth, les tâches en arrière-plan, la localisation, les notifications push, le stockage et la synchronisation doit être remplacé par quelque chose que personne dans l’équipe n’a encore fait tourner en production. C’est dans cette évaluation que les mois s’envolent, et c’est là que se trouve le risque.
Il n’existe aucune partie d’une application mobile pour laquelle nous vous rendrions une liste d’options à étudier. Prenez n’importe quelle partie de l’ancienne application : la réponse existe déjà.
Une analyse des dépendances et des risques de la solution existante : ce qui se transpose directement, ce qui n’a pas d’équivalent, et ce qui ne devrait pas survivre à la migration. Vous obtenez un plan par phases chiffrable, et la migration avance plateforme par plateforme en parallèle de votre feuille de route, sans la geler.
Toutes les missions MAUI ne sont pas des migrations. Nous aidons aussi les équipes qui ont déjà franchi le pas : performances et temps de démarrage, tâches en arrière-plan qui ne se déclenchent plus après une mise à jour de l’OS, handlers et code plateforme, plantages qui ne se reproduisent que sur de vrais appareils, et suivi de chaque nouvelle version de .NET. Faites appel à nous pour une revue, un problème tenace, ou en tant qu’ingénieurs MAUI seniors aux côtés de votre équipe.
Le .NET hérité n’est pas un problème unique. Une application WebForms, une couche de services WCF et un client WinForms bloquent chacun pour des raisons totalement différentes, et une estimation ne vaut que l’expérience réelle de celui qui la fait sur cette technologie. Nous avons écrit du code de production avec chacune d’elles, y compris en VB.NET que personne ne veut ouvrir : l’évaluation relève donc du savoir acquis, pas d’une phase de recherche que vous financez.
Le cycle de vie des pages, le ViewState et les contrôles serveur n’ont pas d’équivalent : le balisage est donc réellement réécrit. La logique métier qu’il recouvre, en général non, et l’essentiel du travail consiste à séparer les deux.
Les bindings, behaviors et contrats SOAP ne se portent pas. Quand les appelants sont des tiers que vous ne pouvez pas modifier, CoreWCF maintient le contrat pendant que tout ce qui se trouve derrière migre.
Il n’y a rien vers quoi migrer : le runtime a disparu de tous les navigateurs. Ces projets commencent par une discussion de cadrage sur ce que l’application devait réellement faire.
C’est dans la couche de données qu’une migration simple devient coûteuse. Traduction des requêtes, transactions et chargement différé se comportent tous différemment, et cela se manifeste en production plutôt qu’à la compilation.
Ce qui se rapproche le plus d’une migration mécanique dans cette liste. Le vrai travail porte sur l’hébergement, la configuration, l’injection de dépendances et le pipeline de middlewares, pas sur vos contrôleurs.
Les deux tournent toujours sur le .NET moderne : c’est donc rarement une réécriture. Ce qui bloque, ce sont les suites de contrôles tierces abandonnées et l’interopérabilité COM, et c’est la première chose que nous cherchons.
Les bibliothèques partagées sont ce qui permet à l’ancien et au nouveau système de tourner côte à côte. Les passer d’abord en multi-ciblage est généralement ce qui débloque tout le reste de cette liste.
Peu glorieux, mais c’est ce qui rend le reste reproductible. Cela porte aussi ses fruits bien avant la fin de la migration, c’est pourquoi c’est souvent la bonne chose à faire en premier.
Rien sur cette liste n’est remplacé d’un seul coup. L’approche qui fonctionne, c’est l’étrangleur (strangler pattern) : mettre en place la nouvelle pile à côté de l’ancienne, migrer une tranche à la fois derrière les mêmes URL, et faire tourner les deux jusqu’à ce qu’il ne reste plus rien côté ancien. Sur le papier, cela paraît plus lent, et c’est la seule version de ce type de projet que nous ayons vue aboutir.
Dites-nous ce que vous cherchez à construire. Nous vous dirons honnêtement si nous sommes la bonne équipe, et ce que nous ferions en premier.
Nous utilisons Google Analytics pour savoir quels contenus méritent d’être développés. Il reste désactivé tant que vous ne l’acceptez pas, et rien sur ce site n’en dépend. Consultez notre politique de confidentialité.
