Comment les développeurs intègrent l'optimisation de tournées
Kardinal a interrogé 145 professionnels, majoritairement 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. Chaque question est présentée sur sa propre base, rappelée sous l'intitulé.
Recevez nos analyses sur l'optimisation de tournées
Actualités produit, benchmarks et analyses sur l'optimisation de tournées. Zéro spam, désinscription en un clic.
Merci, votre inscription est prise en compte.
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 gè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
Type d'organisation, rôle, expérience et implication dans l'optimisation de tournées.
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 ?
Développeurs et ingénieurs forment le premier groupe, devant les CTO et les tech leads.
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 l'optimisation de tournées est traitée, et ce qui coince
Les approches utilisées 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 d'outils reviennent nettement, citées ici par ordre d'occurrence :
Solveurs open-source
- 1.OR-Tools
- 2.VROOM
- 3.Timefold
- 4.pgRouting
Cartographie et routage
- 1.Google Maps
- 2.ESRI / ArcGIS
- 3.GraphHopper
- 4.OpenRouteService
- 5.OSRM
- 6.HERE
Plateformes / TMS
- 1.Kardinal*
- 2.Nomadia
- 3.Ortec
- 4.PTV
- 5.Urbantz
* Cette enquête étant diffusée par Kardinal, ses clients sont possiblement surreprésentés parmi les répondants.
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 ?
Question posée uniquement à ceux qui gè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
Le modèle de déploiement privilégié, les langages utilisés et ce qui compte au moment d'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 ; l'écart entre les critères reste faible (rangs moyens resserrés). Critères classés par rang moyen croissant.
La place des agents IA
L'usage réel des agents de développement et les 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, 2,1 en moyenne.
Tarification et prix caché
Les irritants liés à la tarification et la réaction face à 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 (55 % contre 58 %) : faire soi-même n'élimine pas la difficulté n°1, et expose davantage aux problèmes de performance (53 % contre 37 %) et d'intégration (35 % contre 24 %).
Claude Code est presque toujours accompagné d'un autre outil.
76 % des utilisateurs de Claude Code citent aussi un autre outil (2,4 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 70 %), mais le reste sépare les deux mondes : le C# / .NET marque la logistique (33 % contre 12 %), tandis que les éditeurs utilisent deux fois plus JavaScript / TypeScript (64 % contre 31 %).
La sensibilité au prix caché n'est pas uniforme.
Les éditeurs de logiciels sont les plus rebutés par une API sans prix public (76 % fortement gênés ou refusant d'évaluer, contre 53 % dans la logistique). Les irritants diffèrent aussi : la logistique est plus sensible à l'estimation du volume à l'avance (28 % contre 18 %), les éditeurs à la surveillance de leur usage pour changer de plan (45 % contre 25 %).
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 en constante évolution.
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 intervention manuelle.
Beaucoup développent en interne ou hébergent leur propre solution, mais la maintenance de cette stack reste régulière ou lourde pour une bonne moitié.
Nous opérons l'optimisation en SaaS managé : vous appelez l'API, 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, mostly 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. Each question is shown on its own base, noted below the heading.
Get our route optimization insights
Product news, benchmarks and insights on route optimization. No spam, unsubscribe in one click.
Thanks, you're subscribed.
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
Organization type, role, experience and involvement in route optimization.
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?
Developers and engineers make up the largest group, followed by CTOs and tech leads.
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 of tools stand out, listed here by number of mentions:
Open-source solvers
- 1.OR-Tools
- 2.VROOM
- 3.Timefold
- 4.pgRouting
Mapping & routing
- 1.Google Maps
- 2.ESRI / ArcGIS
- 3.GraphHopper
- 4.OpenRouteService
- 5.OSRM
- 6.HERE
Platforms / TMS
- 1.Kardinal*
- 2.Nomadia
- 3.Ortec
- 4.PTV
- 5.Urbantz
* As this survey was distributed by Kardinal, its customers may be overrepresented among respondents.
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 affects in-house teams as much as everyone else (55% vs. 58%): building it yourself doesn't remove the number-one difficulty, and it exposes teams more to performance issues (53% vs. 37%) and integration issues (35% vs. 24%).
Claude Code almost always comes with another tool.
76% of Claude Code users also cite another tool (2.4 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%, software vendors 70%), but the rest splits the two worlds: C# / .NET is a hallmark of logistics (33% vs. 12%), while software vendors are twice as likely to use JavaScript / TypeScript (64% vs. 31%).
Sensitivity to hidden pricing is not uniform.
Software vendors are the most put off by an API with no public price (76% strongly bothered or refusing to evaluate it, vs. 53% in logistics). Pain points differ too: logistics is more sensitive to estimating volume upfront (28% vs. 18%), software vendors to monitoring usage in order to switch plans (45% vs. 25%).
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.