Comment les développeurs intègrent l'optimisation de tournées
Kardinal a interrogé 145 professionnels de la logistique et de l'édition logicielle sur l'optimisation de tournées : comment ils la traitent aujourd'hui, ce qui coince, les langages et outils qu'ils utilisent, et ce qu'ils attendent d'une API. Cette page en présente les résultats détaillés, restreints aux 99 profils techniques (développeurs, CTO, tech leads, et toute personne qui développe ou intègre elle-même la solution). Chaque question est présentée sur sa propre base, rappelée sous l'intitulé.
Le rapport complet en PDF
Tous les résultats de l'enquête, mis en page pour la lecture et le partage. Entrez votre email, le téléchargement démarre aussitôt.
Merci, le téléchargement démarre…
Ce qu'il faut retenir
Les enseignements principaux, avec les chiffres marquants. Le détail question par question suit ensuite.
Le problème, c'est le terrain
Le décalage avec les conditions réelles est la difficulté n°1 (56 %), devant la performance / temps de calcul (47 %) et les besoins métier mouvants (43 %).
Le fait maison, mais qui coûte cher
L'auto-hébergé reste le modèle privilégié (45 %) et le développement interne domine (56 %). Mais parmi ceux qui opèrent leur propre stack, la moitié déclare une maintenance régulière ou lourde.
Les agents IA, déjà là
Un tiers des répondants utilise un agent dans son workflow quotidien, et seuls 17 % n'en utilisent aucun. Claude Code est de loin le plus cité.
Le prix public compte
Près des deux tiers sont fortement gênés ou refusent même d'évaluer une API sans tarification publique. Documentation et exemples de code priment aussi.
Qui a répondu
Cette lecture regroupe les profils techniques : rôles techniques déclarés, toute personne qui développe ou intègre elle-même la solution, et les rôles « Autre » clairement techniques. Soit 99 des 145 répondants.
Pour quel type d'organisation travaillez-vous actuellement ?
L'échantillon technique est réparti entre opérateurs logistiques et éditeurs de logiciels, au coude à coude, devant les agences et les autres organisations.
Quel est votre rôle principal ?
Les rôles techniques déclarés dominent, complétés par des répondants d'un autre rôle retenus parce qu'ils développent ou intègrent eux-mêmes la solution, ou relèvent d'un profil « Autre » technique.
Avez-vous déjà travaillé sur l'optimisation de tournées ou de livraisons ?
La grande majorité travaille régulièrement ou occasionnellement sur le sujet.
Comment êtes-vous impliqué dans l'optimisation de tournées ?
Une majorité développe ou intègre elle-même la solution, et plus de la moitié décide des outils ou de l'approche.
Comment le problème d'optimisation de tournées est traité, et ce qui coince
Comment le problème d'optimisation de tournées est traité aujourd'hui, les difficultés rencontrées et la charge de maintenance.
Comment le problème est-il traité aujourd'hui dans votre organisation ?
Le développement interne domine largement ; l'API tierce et le traitement manuel arrivent ensuite à égalité, devant l'open-source. Ces approches se combinent : un tiers des répondants en cochent au moins deux, et parmi ceux qui développent en interne, près de la moitié s'appuient aussi sur une autre approche (manuel 24 %, API tierce 20 %, open-source 18 %).
Quel(s) outil(s) ou bibliothèque(s) en particulier ?
Trois familles reviennent nettement : des solveurs open-source (OR-Tools et VROOM en tête, puis Timefold, pgRouting), des APIs de cartographie et de routage (Google Maps, OSRM, HERE, GraphHopper, ESRI / ArcGIS), et des plateformes ou TMS commerciaux (PTV, Ortec, Nomadia, Urbantz, et Kardinal, cités spontanément). Le paysage réel est un empilement : une brique de calcul posée sur une brique de cartographie, souvent complétée de code maison.
Qu'est-ce qui a été le plus difficile ?
Le décalage avec les conditions réelles domine nettement, devant la performance / temps de calcul et les besoins métier mouvants.
Quelle charge de maintenance demande votre stack d'optimisation ?
Posée uniquement à ceux qui opèrent leur propre stack. La charge reste soutenue : la moitié la déclare régulière ou lourde.
Modèle de déploiement, langages, critères d'adoption
Ce que privilégient les profils techniques, dans quels langages, et ce qui compte pour adopter une API.
Pour une capacité comme l'optimisation de tournées, vers quel modèle penchez-vous ?
L'auto-hébergé reste le modèle privilégié, devant l'API managée, avec une part notable d'indécis.
Quels langages utilisez-vous ?
Python domine largement, JavaScript / TypeScript suit.
Au moment d'adopter une nouvelle API, qu'est-ce qui compte le plus pour vous ?
| Critère | Rang moyen | Classé 1er | Dans le top 3 |
|---|---|---|---|
| 1Documentation claire et complète | 3,37 | 26 % (24) | 59 % (54) |
| 2Exemples de code / templates | 3,60 | 14 % (13) | 58 % (53) |
| 3Conseils pour bien modéliser le problème | 3,85 | 18 % (17) | 39 % (36) |
| 4Sandbox pour tester sans engagement | 3,98 | 7 % (6) | 46 % (42) |
| 5Tarification prévisible et transparente | 3,99 | 18 % (17) | 39 % (36) |
| 6SDK bien conçu dans mon langage | 4,50 | 10 % (9) | 35 % (32) |
| 7Temps réduit jusqu'au premier appel | 4,72 | 7 % (6) | 25 % (23) |
Documentation et exemples de code dominent les critères d'adoption ; le classement reste peu polarisé (rangs moyens resserrés). Lignes présentées par rang moyen croissant.
La place des agents IA
Usage réel des agents de développement et outils cités.
Quelle place occupent les agents IA dans votre workflow de développement aujourd'hui ?
Les agents IA sont bien installés : un tiers les utilise au quotidien, et moins d'un cinquième n'en utilise aucun.
Quels outils d'agents utilisez-vous ?
Parmi les utilisateurs d'agents, Claude Code est très largement cité. La plupart n'en utilisent pas qu'un seul : 65 % citent au moins deux outils, soit 2,1 en moyenne.
Tarification et prix caché
Les irritants de pricing et la réaction à une API sans prix public.
Quels aspects de la tarification vous dérangent le plus ?
La facture imprévisible arrive en tête, devant le service coupé en cours de mois et la surveillance de l'usage.
Une API sans tarification publique, où il faut contacter le commercial pour un devis : à quel point cela vous dérange-t-il ?
Près des deux tiers sont fortement gênés ou refusent même d'évaluer une API sans prix public.
Lectures croisées
Ce que révèlent les réponses une fois croisées entre elles.
Faire soi-même ne règle pas le problème du terrain.
Le décalage avec les conditions réelles touche autant les équipes qui développent en interne que les autres (51 % contre 50 %) : faire soi-même n'élimine pas la difficulté n°1, et expose même un peu plus aux problèmes de performance et d'intégration (écart non significatif).
Claude Code est presque toujours accompagné d'un autre outil.
76 % des utilisateurs de Claude Code citent aussi un autre outil (2,1 en moyenne) : GitHub Copilot (40 %), Gemini (30 %), Codex (28 %), Cursor (22 %). Le multi-outillage est la norme.
Chaque secteur a sa signature de langages.
Python domine partout (logistique 56 %, éditeurs 65 %), mais le reste sépare les deux mondes : le C# / .NET marque la logistique (41 % contre 12 %), quand les éditeurs sont deux fois plus sur JavaScript / TypeScript (56 % contre 26 %).
La sensibilité au prix caché n'est pas uniforme.
Les éditeurs de logiciels sont les plus rebutés par une API sans prix public (71 % fortement gênés ou refusant d'évaluer, contre 52 % dans la logistique). Les irritants diffèrent aussi : la logistique redoute surtout d'estimer son volume à l'avance (33 % contre 12 %), les éditeurs de devoir surveiller leur usage pour changer de plan (41 % contre 22 %).
Une API pensée à partir de ces constats
Ces résultats orientent directement la façon dont nous construisons notre API d'optimisation de tournées.
Le décalage avec les conditions réelles est la première difficulté (56 %), devant la performance et des besoins métier qui bougent sans cesse.
Le décalage avec le terrain vient surtout de contraintes réelles que le modèle ne sait pas représenter. Notre moteur en couvre une part inhabituelle : 93 % d'un référentiel de 149 contraintes métier réparties sur 8 secteurs, là où aucun des dix autres moteurs comparés n'atteint 75 % (benchmark d'août 2026). Nous publions aussi un guide et des exemples issus de nos cas réels pour aider à traduire ces contraintes dans le modèle.
La documentation et les exemples de code priment au moment d'adopter une API, et près des deux tiers sont rebutés par une API sans tarification publique.
Une API REST documentée, avec des schémas d'entrée / sortie explicites, des exemples de requêtes exécutables et une grille tarifaire publique. De quoi lire les specs, tester une requête et chiffrer une intégration sans avoir à parler à un commercial.
Les principaux irritants de tarification : une facture imprévisible qui peut s'envoler, et le risque de voir le service coupé en cours de mois.
Une tarification indexée sur une unité lisible et mesurable, le nombre de stops uniques par tranche de 24 h. Le comportement au-delà du plan est défini à l'avance : pas de coupure du service en cours de mois.
Un tiers des répondants fait déjà tourner des agents IA au quotidien, et beaucoup peinent à juger si un résultat d'optimisation est réellement bon.
Une API appelable programmatiquement, qui renvoie des sorties structurées (JSON) accompagnées d'indicateurs sur la qualité de la solution et les contraintes respectées ou violées. Un agent peut ainsi juger un résultat et enchaîner l'action suivante sans passe manuelle.
Beaucoup développent en interne ou s'auto-hébergent, mais la maintenance de cette stack reste régulière ou lourde pour une bonne moitié.
Nous opérons l'optimisation en SaaS managé : l'API est appelée, nous prenons en charge le solveur, le tuning et les mises à jour d'algorithme. La maintenance de la brique d'optimisation ne repose plus sur vos équipes.
Testez l'API sur vos propres tournées
Documentation claire, schémas d'entrée / sortie, exemples de requêtes exécutables et grille tarifaire publique. Créez un compte et lancez votre premier appel, sans passer par un commercial.
How developers integrate route optimization
Kardinal surveyed 145 professionals from logistics and software vendors about route optimization: how they handle it today, where it breaks down, the languages and tools they use, and what they expect from an API. This page presents the detailed results, restricted to the 99 technical profiles (developers, CTOs, tech leads, and anyone who builds or integrates the solution themselves). Each question is shown on its own base, noted below the heading.
The full report in PDF
All the survey results, laid out for reading and sharing. Enter your email and the download starts right away.
Thanks, your download is starting…
Key takeaways
The main findings, with the standout figures. The question-by-question detail follows.
The problem is the field, not the algorithm
The gap with real conditions is the number-one difficulty (56%), ahead of performance / compute time (47%) and shifting business needs (43%).
Build-it-yourself, but costly
Self-hosting stays the preferred model (45%) and in-house development dominates (56%). But among those who operate their own stack, half report regular or heavy maintenance.
AI agents are already here
A third of respondents use an agent in their daily workflow, and only 17% use none. Claude Code is by far the most cited.
Public pricing matters
Nearly two-thirds are strongly bothered or refuse to even evaluate an API with no public pricing. Documentation and code examples come first too.
Who responded
This edition groups the technical profiles: declared technical roles, anyone who builds or integrates the solution themselves, and clearly technical “Other” roles. That is 99 of the 145 respondents.
What kind of organization do you currently work for?
The technical sample splits between logistics operators and software vendors, neck and neck, ahead of agencies and other organizations.
What is your main role?
Declared technical roles dominate, complemented by respondents in another role kept because they build or integrate the solution themselves, or fall under a technical “Other” profile.
Have you ever worked on route or delivery optimization?
The vast majority works on it regularly or occasionally.
How are you involved in route optimization?
A majority builds or integrates the solution themselves, and more than half decides the tools or approach.
How the route optimization problem is handled, and where it breaks down
How the route optimization problem is handled today, the difficulties faced and the maintenance burden.
How is the problem handled today in your organization?
In-house development dominates; third-party API and manual handling come next, tied, ahead of open-source. These approaches combine: a third of respondents pick at least two, and among those who build in-house, nearly half also rely on another approach (manual 24%, third-party API 20%, open-source 18%).
Which tool(s) or library(ies) specifically?
Three families stand out clearly: open-source solvers (OR-Tools and VROOM leading, then Timefold, pgRouting), mapping and routing APIs (Google Maps, OSRM, HERE, GraphHopper, ESRI / ArcGIS), and commercial platforms or TMS (PTV, Ortec, Nomadia, Urbantz, and Kardinal, named spontaneously). The real landscape is a stack: a compute layer on top of a mapping layer, often topped with in-house code.
What was the hardest part?
The gap with real conditions clearly dominates, ahead of performance / compute time and shifting business needs.
How much maintenance does your optimization stack require?
Asked only to those who operate their own stack. The burden stays high: half report it as regular or heavy.
Deployment model, languages, adoption criteria
What technical profiles prefer, in which languages, and what matters when adopting an API.
For a capability like route optimization, which model do you lean toward?
Self-hosted remains the preferred model, ahead of the managed API, with a notable share undecided.
Which languages do you use?
Python dominates by far, JavaScript / TypeScript follows.
When adopting a new API, what matters most to you?
| Criterion | Mean rank | Ranked 1st | In the top 3 |
|---|---|---|---|
| 1Clear, complete documentation | 3,37 | 26 % (24) | 59 % (54) |
| 2Code examples / templates | 3,60 | 14 % (13) | 58 % (53) |
| 3Guidance on modeling the problem well | 3,85 | 18 % (17) | 39 % (36) |
| 4Sandbox to test with no commitment | 3,98 | 7 % (6) | 46 % (42) |
| 5Predictable, transparent pricing | 3,99 | 18 % (17) | 39 % (36) |
| 6Well-designed SDK in my language | 4,50 | 10 % (9) | 35 % (32) |
| 7Short time to first call | 4,72 | 7 % (6) | 25 % (23) |
Documentation and code examples lead the adoption criteria; the ranking stays weakly polarized (mean ranks are close). Rows shown by increasing mean rank.
The place of AI agents
Actual use of development agents and the tools named.
How present are AI agents in your development workflow today?
AI agents are well established: a third use them daily, and fewer than one in five use none.
Which agent tools do you use?
Among agent users, Claude Code is very widely cited. Most use more than one: 65% name at least two tools, i.e. 2.1 on average.
Pricing and hidden price
Pricing frustrations and the reaction to an API with no public price.
Which aspects of pricing bother you most?
The unpredictable bill leads, ahead of service cut off mid-month and having to watch usage.
An API with no public pricing, where you must contact sales for a quote: how much does that bother you?
Nearly two-thirds are strongly bothered or refuse to even evaluate an API with no public price.
Cross-cut readings
What the answers reveal once cross-analyzed.
Building it yourself doesn't fix the field problem.
The gap with real conditions hits in-house teams as much as the rest (51% vs 50%): building it yourself doesn't remove the number-one difficulty, and even exposes you slightly more to performance and integration issues (difference not significant).
Claude Code almost always comes with another tool.
76% of Claude Code users also cite another tool (2.1 on average): GitHub Copilot (40%), Gemini (30%), Codex (28%), Cursor (22%). Multi-tooling is the norm.
Each sector has its own language signature.
Python dominates everywhere (logistics 56%, vendors 65%), but the rest splits the two worlds: C# / .NET marks logistics (41% vs 12%), while vendors are twice as much on JavaScript / TypeScript (56% vs 26%).
Sensitivity to hidden pricing is not uniform.
Software vendors are the most put off by an API with no public price (71% strongly bothered or refusing to evaluate, vs 52% in logistics). The frustrations also differ: logistics mostly dreads estimating volume upfront (33% vs 12%), vendors having to watch usage to switch plans (41% vs 22%).
An API shaped by these findings
These results directly shape how we build our route optimization API.
The gap with real conditions is the number-one difficulty (56%), ahead of performance and constantly shifting business needs.
The gap with the field comes mostly from real constraints the model can't represent. Our engine covers an unusual share of them: 93% of a reference set of 149 business constraints across 8 sectors, where none of the ten other engines compared reaches 75% (August 2026 benchmark). We also publish a guide and examples drawn from our real cases to help translate these constraints into the model.
Documentation and code examples come first when adopting an API, and nearly two-thirds are put off by an API with no public pricing.
A documented REST API, with explicit input / output schemas, runnable request examples and a public pricing grid. Enough to read the specs, test a request and price an integration without having to talk to sales.
The main pricing frustrations: an unpredictable bill that can spike, and the risk of the service being cut off mid-month.
Pricing indexed on a readable, measurable unit: the number of unique stops per 24-hour window. Behavior beyond the plan is defined upfront: no service cut-off mid-month.
A third of respondents already run AI agents daily, and many struggle to judge whether an optimization result is really good.
A programmatically callable API that returns structured output (JSON) with indicators on solution quality and which constraints are met or violated. An agent can thus judge a result and move to the next action without a manual step.
Many build in-house or self-host, but maintaining that stack stays regular or heavy for a good half of them.
We run optimization as managed SaaS: the API is called, we handle the solver, tuning and algorithm updates. Maintaining the optimization layer no longer falls on your teams.
Test the API on your own routes
Clear documentation, input / output schemas, runnable request examples and a public pricing grid. Create an account and make your first call, no sales call required.