It is tempting to put artificial intelligence at the top of every promise. The recent interview with Fabien Pinckaers, founder of Odoo, usefully recalls an obvious point too often forgotten: AI is only a means. One algorithm among others. What matters is not the fad, but the ability to solve real problems in very concrete companies, with a benefit that is visible every day.
This article offers a structured reading of what can be taken away from that conversation: the technical ambition behind Odoo, the exact place of AI, and – above all – the conditions for success of a pragmatic, lean and effective transformation project.
1) AI in its proper place: useful when it is the best answer
The right question is not "can we do AI here?" but "what problem are we trying to solve?". If a business rule, a statistical calculation or a simple automation is enough, you choose the most robust and fastest route. AI comes in when it brings more precision, speed or autonomy than the alternatives.
Telling examples mentioned in the interview:
- Accounting: invoice recognition and pre-filling to reduce manual entry.
- Incoming documents: sorting and routing according to explicit instructions (convert to invoice, start a signature flow, open a case).
- Project management: automatic task assignment according to readable rules.
- Support: fewer recurring tickets thanks to an agent backed by the real data of the information system.
What they have in common: concrete micro-gains that add up and free up useful time.
2) A technical ambition: from utopia to industrialization
Covering all of a company's processes without sinking into an overcomplicated "monster" requires a modular architecture designed like a tree:
- a trunk of shared objects (contacts, products, documents, etc.),
- branches (sales, purchasing, manufacturing, accounting, website…),
- leaves: fine-grained adaptations per industry.
This arrangement makes it possible to reuse proven building blocks (statistics, views, website, documents) and to add only a thin business layer to create a new application. The result: performance without miracles, just well-thought-out engineering.
A direct consequence: the end-to-end chain stays readable. An email campaign leads to an opportunity, then to a quotation, an order, a delivery, an invoice and a payment: traceability happens naturally and the attribution of results becomes factual.
3) An open and pragmatic model
Rather than opposing dogma and economic reality, Odoo embraces a dual-license model: an open core (accessible code) and proprietary add-ons that fund the industrialization effort.
The consequence, again, is very practical: the community can contribute, extend and publish modules; the publisher ensures long-term sustainability and quality. In other words, no ideology, just what is useful and effective.
4) Answering the recurring criticisms
a) Data sovereignty and reversibility
Sovereignty cannot be decreed; it has to be prepared. Natively, Odoo technology combined with Odoo.sh hosting provides:
- data reversibility, through full exports and open formats;
- CSV/JSON exports including, if needed, attachments;
- a documented API (JSON-RPC / XML-RPC) to automate extractions;
- daily backups with defined retention and restore procedures;
- the option of a full database export (dump) on request;
- a staging/test environment to test data retrieval (export/import) before going live;
- a suitable choice of hosting: online service, Odoo.sh platform or the company's own servers.
b) Dependency and migrations
Changing ERP is demanding with any vendor. Success factors come down to data quality, a controlled scope, and an export/import procedure proven on a prototype before roll-out. Governance and acceptance criteria must be shared.
c) Support and performance
Performance is managed: service objectives, monitoring, logging, reasoned updates and custom developments limited to the strict minimum (configure first, develop afterwards).
d) Cost and value
The subscription model funds legal/tax compliance and continuous improvements. When a strong need for control arises, the on-premise option remains. The trade-off is economic and business-driven, not ideological.
5) Success conditions for an Odoo project (Auguria's lessons learned)
- Start with the essential flows
Sales: quotation → order → delivery → invoice → payment.
Purchasing: request → order → receipt → invoice → payment.
Secure first what creates and protects value. - Standard first, adaptation later
Configure before developing. Only code when the need is recurring, quantified, lasting. - Clean data model
Clear master data (products, customers, suppliers), naming rules, consistency checks. - Short iterations, quick proof
Small steps, visible benefits, lessons learned built in. - Useful indicators
A few metrics that guide action rather than an encyclopedic dashboard. - Training and documentation
Explain who does what, when, how. A clear process beats a long tutorial. - Reversibility plan
See the dedicated section: it is an insurance policy that requires good data practices. - Update policy
A regular, controlled rhythm rather than a big leap every three years. - Selection of external integrations
Connect what makes sense: stable API, clear contract, genuinely useful data. - Reality-driven management
Decide on evidence: data, tests, user feedback. A successful trial comes first.
Conclusion: modernizing without abandoning common sense
The interview highlights a discipline we hold dear: start from real flows, keep data in good order, and choose the tool that is most proportionate to the problem. AI has its place, but on demand and in service of day-to-day execution.
Less technical tangle, more operational clarity.
At Auguria, we stand by this approach: standard first, adaptation when it brings a measurable gain, and support that secures data, people and the long term. If you are considering modernizing your processes, let's start small, move fast and know why we are moving.